On Sun, 2 Nov 2008, Markus Neteler wrote:
Hi Paul, all,
On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
<paul-grass@stjohnspoint.co.uk> wrote:
Hi Markus
On Sun, 2 Nov 2008, Markus Neteler wrote:
(cc Tim Sutton)
On Mon, Oct 27, 2008 at 7:30 AM, Hamish <hamish_b@yahoo.com> wrote:
Paul wrote:
I still think at some point a 6.4 release branch will be needed (when we
want to add new features) but I think we should put off creating it as
long as possible to reduce work. That's all - it depends on other
developers agreeing to restrict the changes we make to develbranch_6
for a while though.
There is an additional reason:
QGIS is going into feature freeze (they are already at 1.0 Preview 1).
I really want to avoid that they have to package 6.3.0 into it, just
because some GRASS developers are unhappy to see a 6.4.0
release branch.
Can you explain further? If we say that develbranch_6_4 is not going to have
new incompatible features added to it before releasebranch_6_4 is created,
This is a not easy goal, but we can try. Simply *all* devs have to accept
a feature freeze (in the past we weren't very successful on that AFAIR).
is that enough? I can't imagine that we would need to create a release
branch before it is absolutely necessary, just to give reassurance to the
QGIS developers that we are going to keep our word not to add new
incompatible features?
That's not the point I think. I spoke to Tim Sutton in Cape Town.
What they need is a release (candidate) to work with. A moving
target like devel_grass6 isn't acceptable for them.
Ah yes I understand. But my point was we don't need a release branch to create 6.4.0RC1, if we are disciplined about new features.
We can certainly freeze devel_grass6 and just tag RC1 directly from that
and test it rigorously. But are we sure that nobody inserts new features?
This is really important. It is of general importance to GRASS actually (a PSC issue I suppose, but better to discuss it here) because of the OSGeo requirements for quality control etc., and for the PSC to maintain that quality control. Our quality control model is a very basic "developers are allowed to make changes to the codebase as they see fit". I think this works very well for nearly everything but if you feel we may have problems with communication then we need to discuss it.
As a team of developers, we don't have the equivalent of an evil overlord or a benevolent dictator to approve every SVN commit or to keep an eye on everything that's going on and speak to individual developers if they commit something that doesn't seem in policy. GRASS is too big and complicated and diverse for that. We really rely on developers keeping the grass-dev list updated with what they're doing, and summarising the reasons for changes they're making. If somebody says:
I've committed (or am about to commit) the following changes to module X
There were previous problems X, Y and Z
These changes fix the problems by eliminating step Q
or that kind of thing, it's easy for others to see the motivation behind the changes and comment on the appropriateness or otherwise of the way things are being done. When this happens and feedback is given it generally works very well, but it relies to a certain extent on other developers taking the time to review the changes. I suspect some developers get disheartened if they do this and noone has the time to review and reply at the time, and then they don't bother in future. That can be particularly off-putting for new or occasional developers.
But the thing is, even if this happens, IT IS NOT WASTED EFFORT! I know from experience that just taking the time to explain to others the changes you are making can make them make much more sense in your own head, and the mailing list archives are always going to be there in future, which future developers can search to find the reasoning behind a particular change. So it is always a good idea to keep grass-dev updated with what you are working on. Around the time of a release when we are deciding what to put in and keep out, this is particularly important.
Especially in the wxPython arena, there are a couple of issues yet to be
submitted (AFAIK) which would easily count as new feature.
Then these features should be discussed on grass-dev and we should come to a consensus if they are needed for 6.4.0 or can be held back. IMHO, probably controversial, there are still enough regular bug reports for the wxPython GUI that it is not ready to go into a stable release. IIUC there are also still issues with wxwidgets versions on various platforms. I still see wxGUI as the futuristic 7.x GUI, especially given we are doing the wholescale move towards Python (rewriting scripts etc.) for 7.x anyway. gis.m has had loads of bugfixes since 6.2 and I think it should be the standard promoted GUI in 6.4. But I would love to see more discussion of the wxGUI on grass-dev.
Paul