[GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Moritz Lennert]

On 06/04/14 13:46, Hamish wrote:

> First of all, I believe this discussion belongs on the grass-dev list, not PSC. See RFC1.

CC'in to dev-list


> releasebranch70 should not have been branched until 7.0RC1. Until RC1
> it is just wasted effort to keep the two of them as a 1:1 mirror, so
> what's the point? If anyone wants to talk about unnecessary developer
> burden, start there.

As already mentioned I was also a bit surprised by this. I'm not sure we 
are really ready for something more than a tech-preview (and not a real 
release), but maybe it could be the kick in the behind that we need to 
once and for all move over to GRASS7 as the main official branch...

I also think that voting on Martin's proposal as such is a bit 
premature. I think we should discuss the pros and cons of different 
approaches a bit more before calling a vote.

I think that experience has shown that the lack of clear policy on 
release management has caused frustration among developers. Personally, 
I'm somewhere between the two approaches. On the one hand what I 
understand to be Hamish' wish of having a debian-like system of unstable 
for ongoing cutting-edge development, testing as a staging area for more 
stabilized code and stable as rock-solid, albeit a bit outdated, On the 
other hand, I just haven't seen this work in GRASS up to now and I see a 
lot of frustration from those who find this system too heavy to carry. I 
don't know if that is because the procedure never was clear or whether 
we lack the equivalent of the debian ftp-managers to oversee the 
process, whether we just lack the discipline (which could be linked to 
the previous point) or whether the GRASS development team is just too 
small for such a process. One of the big differences, IMHO, is that a 
user of debian testing just has to apt-get update && apt-get upgrade to 
get the lasted developments, whereas users of grass6dev has to compile 
it themselves (at least on GNU/Linux) as no distribution offers packages 
for that. This means that using testing is a much more involved process.

So, before we start voting of release procedures, maybe we have to first 
clarify and agree upon our goals. I.e. decide on the ends before we 
decide on the means.

Here is my attempt on some of the goals:

- provide a rock-solid, "just works", version of GRASS
- provide easy access for users to new developments in GRASS
- keep the burden on the dev-team as low as possible
- make the whole development and release process very clear and explicit 
with defined procedures and (at least relative) timetables
- enforce a certain level of discipline in the respect of these rules 
and procedures

> As mentioned before, I wish to use the bulk of my grass dev time
> maintaining the grass 6 line. To do that properly I need a staging
> area, and devbr6 is it. Hosting a clone on github for that is too
> ridiculous and broken a situation to begin to contemplate.
>
> If devbr6 is removed I simply can not do the stable grass 6
> maintenance job properly. So without that there is really very little
> for me to contribute in future. It will not translate to me spending
> more time working on grass 7, only drive me away from the project.

I think that seen Hamish' continued effort for this project this a 
serious enough situation to demand a solution.

But maybe the idea to actually release a first version of grass7 in a 
not to far future is a way out.

Hamish, maybe you could be the official grass6 maintainer, managing the 
whole grass6 development in the way you propose, i.e. any new 
development and bugfixes first go into grass6dev for a period of 
testing, before _you_ make the decision that something can be backported 
to grass6release. I do think however, that for this to work, we would 
need to regularly publish snapshots of grass6dev for easy testing.

All other devs only commit to grass6dev, never to grass6release.

Just my 2¢,

Moritz