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
_______________________________________________
grass-psc mailing list
grass-psc@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-psc
