[GRASS-dev] GRASS 6.4.0 release branch forthcoming

[Paul Kelly]

On Sun, 2 Nov 2008, Markus Neteler wrote:

> Hi Paul, all,
>
> On Sun, Nov 2, 2008 at 5:59 PM, Paul Kelly
> <paul-grass at 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 at 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