ATTN: Merging changes to the release branch
Folks, 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. Thanks, -- Aleksey Gurtovoy MetaCommunications Engineering
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. Firstly, when I fix something in a release candidate branch (RC) I want to test it in RC and check it in in RC (and not test it in MAIN and check it in on MAIN and then merge to RC). Secondly, no changes can go from MAIN to RC but only from RC to head. This protects RC against such errors. Thirdly, if I manage to mess up the merge process, usually only MAIN is affected and not RC. Markus
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. Keeping the RC clean is a higher priority than keeping the trunk clean. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
OK So we checking to the mainbranch, wait for testing to be completed and merge changes to RC? Where are the test results for the main branch to be found? All I can find are those for the RC? Robert Ramey "David Abrahams" <dave@boost-consulting.com> wrote in message news:ufz3xtcq7.fsf@boost-consulting.com... 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. Keeping the RC clean is a higher priority than keeping the trunk clean. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
At 03:38 AM 10/30/2004, Markus Schöpflin wrote:
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.
We used to do it the way you suggest. We have had far less problems since we changed to the current procedures. IIRC, part of the problem with going from RC to main was that if that when the merge step got forgotten, there was often a considerable time delay before anyone realized there was a problem. That made it more difficult to figure out what was wrong. OTOH, if a merge from main to RC is forgotten then it is detected quickly because there are a lot of eyes looking at the RC and RC tests. Since the change is fresh in the developer's mind, the developer usually knows instantly what happened and can fix it quickly. --Beman
At Saturday 2004-10-30 07:18, you wrote:
At 03:38 AM 10/30/2004, Markus Schöpflin wrote:
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.
We used to do it the way you suggest. We have had far less problems since we changed to the current procedures.
IIRC, part of the problem with going from RC to main was that if that when the merge step got forgotten, there was often a considerable time delay before anyone realized there was a problem. That made it more difficult to figure out what was wrong.
OTOH, if a merge from main to RC is forgotten then it is detected quickly because there are a lot of eyes looking at the RC and RC tests.
if you were merging the other way none of us testers would have had to change our procedures and we'd be testing the main branch like always. You'd detect the problem JUST as quickly
Since the change is fresh in the developer's mind, the developer usually knows instantly what happened and can fix it quickly.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Markus Schöpflin wrote:
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.
In many projects, there is no such thing as "merging to the release branch" or "merging from the release branch." If a patch to mainline also qualifies for the release branch (for example, it fixes a regression), then it is committed to the release branch at the same time. If a patch fixes a regression only present on the release branch, then it is committed to the release branch only. And, of course, diffs for all patches are carefully checked, and patches are regression tested before commit, so there aren't any mistakes in the first place, right? :-) Aaron W. LaFramboise
participants (8)
-
Aaron W. LaFramboise -
Aleksey Gurtovoy -
Beman Dawes -
David Abrahams -
Markus Schöpflin -
Markus Schöpflin -
Robert Ramey -
Victor A. Wagner Jr.