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