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