[GRASS-dev] too many branches

[Hamish]

Martin wrote:
> well, the real point is that we should focus our energy on
> GRASS 7 development, and not playing with GRASS 6 as we do
> now.

er, we _are_ focusing our energy on GRASS 7 development... ?

and we absolutely should pick and choose which /tested/ bug
fixes go in to the next 6.4.x stable release, from a close by
code base.


> Is there any comparison of devbr6 a relbr64? I am pretty sure
> that many changes, fixes which has been committed to devbr6
> were not applied later in relbr64.

very serious question: does it matter? if it is a serious bug
fix then sure it should make it into the release branch, and
if it diverges too far from 6.4 and is not intended to be
backported, then it arguably shouldn't have been put in there,
but if it is just sitting there collecting dust and not doing
anyone harm, who cares? if it is important enough it'll get
where it needs to be. If not, let it collect dust & not hurting
anyone.

> It's too time/energy consuming for so small dev team to
> maintain so many branches.

from my POV it's no trouble at all. I've always been of the
mind that devbr6 should only exist in svn, no need for nightly
snapshots or automated builds; although I have to admit that
those extras have found bugs quickly and have allowed us to get
bug reports from users who would never have checked out code from
svn and built it themselves before the thing made it into 6.4.
If just a single link to the 6.5 svn remained on the download
page I would not be sad.
 
> It's really time to focus on grass7

besides some maintenance release work for the stable branch right
now, AFAICT we _are_ focusing development on trunk. And if 1 dev
wants to spend their time working on old 5.x code or whatever, so
what? It's their time not anyone else's.


> (if we really want to release this version in reasonable time,
> less then one year or so).

have we set release goals? e.g. is the LGPL IO lib for GDAL
going to happen to allow us to rework the raster directory
layout for grass 7.


> I fully agree with MarkusM, it's time to kill devbr6.

If it gets to the point where I have to fork a copy of devbr6
onto github because it is still useful to me, well that's such
a level of dysfunctionality and craziness that I don't even
want to think about it much. I don't understand why 6.5 just
can't be left to slowly fade away like the 5.5 devbr was & still
is.

Glynn:
> If a change is too invasive to go into the 6.4 branch, it
> belongs on the 7.0 trunk.

AFAIK we don't have anything like that happening. Asking code
to be perfect the moment it gets backported from trunk to the
release branch is a bit much IMO. And AFA I'm concerned, we
should only apply rock solid code to 6.4 branch, and devbr6
gives us a little breathing space.


thanks,
Hamish