Some pedantic but by my experience useful steps added below, (lessons learned as I messed things up at each one of these steps in the past)
Glynn wrote: > To clarify: 0. 'cvs update' to be sure you are working with the latest version. > 1. Make changes to the local copy of the trunk. 1.5 'cvs diff' to check for left over temporary debug messages, unnecessary whitespace changes, etc. > 2. Commit the changes. 2.5. Decide if the change is suitable for backporting. > 3. Change directory to the local copy of the branch. > 4. Use "cvs update -j ... -j ..." to synchronise the branch to the > trunk. 4.5 'cvs diff' check again. > 5. Commit the changes. As to deciding what is suitable for backporting, I am of two minds. On one hand it is very useful to have some sort of deadline to motivate us to fix as many old lingering bugs as possible before the release. On the other hand even small modifications to critical modules like g.region and r.out.gdal days before release are very dangerous. Those need maximum testing time in the development branch to avoid nasty unintentional side effects. It has been typical for that sort of mistake not to be spotted even in the well tested CVS/HEAD version for months. A good rule seems to be only backport important bug fixes and well-tested important updates. Leave anything else to a future release. 6.3.0 is not intended to be as stable as 6.2, so I wouldn't worry so much about that here, for 6.3 it becomes more a question of if the backporting justifies the double effort. The stable branch CVS mostly goes untested before release, so any change there has to be very carefully done. Hamish __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
