David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
Aleksey Gurtovoy wrote:
Can I gently ask everybody to be more careful with integration of changes from the main trunk to the release branch? If you have to do it, please double-check everything (in particular, run the diffs) before committing the merged files. We've already got the new "boost/index.html" contents with *1.33.0* section stub in the release branch, and dealing with more of something like this is not going to help the release.
I'm wondering why the procedure isn't the other way round, eg. first check in on the release branch and then merge the fix onto the main branch if it affects the main branch as well.
We used to do it that way. People would check things in on the RC branch without enough testing. At least if you check into the main trunk first, you can find out if tests break before you merge into the RC.
But running the tests on the main branch doesn't tell you a thing about the results of the tests in the RC branch. So how are you supposed to find out that a change would break the RC branch? Besides, there are currently only regression tests run for the RC branch and not the main branch, AFAICT.
Keeping the RC clean is a higher priority than keeping the trunk clean.
That's exactly why I was proposing that the changes should go the other way round, not from main to RC but from RC to main as the danger is quite high that you merge something to RC that you didn't want to merge. Markus