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