[GRASS-PSC] too many branches => retirement GRASS6.5.svn (=develbranch6)

[Hamish]

Hi,

I wrote - and thought, sent - a long email about this some days ago, but yahoo or something seems to have eaten it as I don't see it in the list archive. frustrating as I already cleared my local copy!


First of all, I believe this discussion belongs on the grass-dev list, not PSC. See RFC1.


it's late on Sunday night so I won't restart the whole thing right now, but long story short, and not stated nearly as clearly or well-


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. (fwiw it is possible to add a hook to auto-merge in svn server-side) Also, I was rather surprised to see beta1 released at all as AFAIK we had only discussed a "technology preview", ie a tag direct from trunk. Sorry if I missed some email, otherwise I would have raised this earlier.


GRASS 6.x is already far along into bugfix maintenance mode. *Please, just leave it to naturally and quietly make its way into history.*

Note that for copyright and critical bug reasons relbr64 must be release-ready within a few hours (or days) at all times. There are various debug codes and experiments in devbr6 which are not suitable for backport but none the less useful to have around. Right now with 6.4.4 deeply frozen there are things for some future 6.4.5 in devbr6 which are not critical enough to push in for 6.4.4 this late in the cycle. Maintaining a local patch set for those instead is lossy and frankly, dumb.

tbh I cringe every time I see a commit go into both relbr64 and devbr6 at the same time, as it pretty much guarantees the changes were only lightly tested by only one or a few people, which is not how it should be done, especially when we are so close to release. Minor innocent looking last minute changes have resulted in embarrassing major problems multiple times in the past, time and discipline is the only way to deal with it. This will only get more risky as 6 and 7's libraries diverge.  Direct backports are personally frustrating as they undermine and short-circuit hours of other careful merging and checking, and generally treating the relbr64 codebase like a delicate and valuable antique vase.

In grass-addon/tools/ svn repo you will find a number of svnXXmerge scripts for porting between branches which makes maintaining multiple branches completely trivial. The difficult and risky park is porting between 6 and 7.  Between 6.4 and 6.5, and 7.0 and 7.1 is trivial to merge with those scripts given a svn rev number, and little risk. Porting 7.x direct to 6.4 is high risk and a threat to our reputation as uber-stable software, which we have fought very hard to obtain and should protect at all costs. I don't think I can be part of the ruin of that.


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've thought long and hard about this, and it has caused me much upset and anguish, since I enjoy working on GRASS and do not want to have that taken away. Having the stable release getting only better with time takes discipline, procedure, and yes, work.

There is simply no two ways around that.

regards,
Hamish