Hamish escribió:
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.
Perfectly clear now, thanks both of you
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.
My changes only affect internationalized messages, so they neither fix
important bugs nor should create them, so the effort is the only thing
in mind.
Thanks again for the information.
Carlos
_______________________________________________
grass-dev mailing list
[email protected]
http://grass.itc.it/mailman/listinfo/grass-dev
