[GRASS-dev] too many branches

[Glynn Clements]

Hamish wrote:

> 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 wouldn't hold your breath on that one.

In order to safely exorcise the GPL, the job needs two people. One who
can write the code for GDAL without looking at the GRASS code, and one
to provide specifications and clarifications based upon the GRASS
code. I can do one of those (preferably the latter, as I've been
involved in most of the substantial raster I/O changes since 6.0 and
maybe earlier), but the other post remains unfilled after ~4 years.

> 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.

The breathing space is provided by the fact that the branch is a
branch, not a release. So long as people don't back-port code a few
days before the branch is due to be tagged for release, there
shouldn't be a problem.

Right now, we offer four levels of stability: 6.4.2, 6.4 branch, 6.5
branch, 7.0 trunk. We could afford to lose the 6.5 branch; 6.4 ought
to be stable enough for a branch.

Anyone running code from a branch has to be willing to deal with the
possibility that they might grab the version immediately after a bad
commit. If they can't, they should be using a release rather than a
branch.

The presence of 6.5 doesn't eliminate the possibility of a bad commit
to 6.4. It doesn't necessarily even reduce it all that much.

If bug-fixes get back-ported to 6.5, then to 6.4 shortly thereafter,
any mistakes are more likely to be found once they reach 6.4 than in
the short time that they live on 6.5, getting tested by a handful of
users (there isn't much incentive to run 6.5 if it's just 6.4 with a
slightly increased chance of bugs).

OTOH, if there are more substantial differences between 6.4 and 6.5,
then a successful fix in 6.5 is no guarantee of success in 6.4.

-- 
Glynn Clements <glynn at gclements.plus.com>