[GRASS-dev] too many branches

[Hamish]

Markus M:
> My ;-) was kind of a teaser. I regard 6.4.svn as more stable than
> 6.4.2.

I don't think it matters much, but for the purposes better discussion
I think it's worth pointing out that I am perhaps using a slightly
different definition of "stable" than you. To me, "stable" includes
well tested, bugs (and perhaps work arounds) are known. Untested code
with bug fixes applied is to me less stable, and I would not give it to
a new user or use in a production environment since it hasn't been through
the same QA labors. That's not to say that either definition is better
than the other, or others should make recommendations following my thoughts
on the matter, just the definition from the POV I'm looking at it from.


> You said that there is no stable 6.4.3 that a user could see.
> [This is directed at all other devs:] Then we should make sure that
> there is a stable 6.4.3 that a user could see.

[devil's advocate] .. why not just do away with releases then and promote
the nightly builds as a rolling release?
[no, I'm not really suggesting that]

but really, for the stable release I'd be happy to see monthly releases
to add in new bug fixes (but only bug fixes :), subject to longer or
shorter cycles depending on how important the bugs found in that cycle were,
eventually trailing off to infinity like 5.4.x.

I was under the assumption that there were no major bugs in 6.4.2, so
hadn't been too worried that it has taken a bit longer. I had hoped the
broken addons repo for the MS Windows version could be taken care of by
a quick 6.4.2-3_setup.exe rebuild, but that didn't happen.

The news that there was a flaw in the wxGUI is news to me in the last
few days, and I would have pushed for a smaller-but-faster 6.4.3 release
sooner if I had realized that there were important bugs holding people
back.


> At the the very least, please release 6.4.3rc1 before yesterday
> (commonly used deadline definition).

anyone have ideas on this one?
#1692  	 calling a script within a script failing on Windows XP
v.db.* and lots of other fail.

wrt blockers, I'd take the stance that it just has to be less-broken
than 6.4.2, releasing a 6.4.3 with known flaws that were also in 6.4.2
is not the end of the world, but it is useful to harness the pre-release
energy to try and fix such things.

I'll note that I had been using devbr6 for experiments and adding debug
messages in ways I'm not comfortable doing in the 6.4 release branch to
investigate this particular bug (hmm, actually it might have been the
clean_temp.exe bug. no matter). Then I'd wait for the next nightly build,
test, and repeat.


Helena:
> After reading through the entire discussion I think even Hamish would
> agree that there is a broad consensus that the number of branches needs
> to be reduced (as I read it, it should be grass64 and grass7)

There is no support for that from me.  Devbr6 (I'll try to stop calling it
6.5svn, we had a discussion about that months ago) is highly useful to me,
I use it almost every day, and I'd be very upset and inconvenienced if it
were removed from svn. It has maturing code aimed for future stable releases
beyond the immediate next one, and backporting fixes from trunk directly
is not always a trivial task. (e.g. see r52853)

> and the sooner it is done, the fewer problems and confusion there will be.

please, just let it slip away into old age and irrelevance in peace like
devbr5_5 ...


I think too much is being made of it, primarily because have been distracted
by other work and left small bugfixes too long waiting to be backported,
which accounts to many of the 'problems' -- the gardening I'd quietly been
doing there had been left unattended for while and started to fall on other
people. In general I am quite happy to volunteer to maintain the stable
branch(es), even if I have to do that alone, but from time to time the day
job and real life pull me away so it is not always as immediate as I'd like.

wrt the 'confusion' issue, I fully agree that the downloads page should be
cleaned up, and 6.5 de-emphasized there to a single line. I'd already added
discouraging "(restricted development; testbed for backporting, ... Utility
version for developers." text to it, and would not at all mind its table
being reduced to a simple link to
  http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS6.5

even though, as mentioned above, the nightly Windows builds of it have
helped me to work on bugs in 6.4 in the past, in an environment where I
could experiment safely.


As for releasebranch_6_4 (calling it 6.4.3 is confusing I think), IM 2c O
that should also be a one-liner on the download page, but if there are
pending (important) bug fixes we should aim for minimal-change monthly
releases, instead of long waits between big releases and then higher-
stress to get them out the door.


wrt cutting a release branch for trunk, IMO to avoid double merging that
should wait as long as possible until we have identified release goals
and are nearing the bug-fixes-only stage. Even then we can rely on personal
discipline for a time instead of needing a special branch.



thanks,
Hamish

ps- hot off the press, checkitout:  http://live.osgeo.org