[1.45.0] Permission to merge trunk to release for Boost.Optional
Hi, As reported by Eric Niebler, the release brunch did not had the swap member that existed in the trunk for a long time. I just merged it locally and run the tests on the release branch. Can I commit the changes? P.S: The test suite changed as well due to the different swap. P.S.2: I've also been reported on a couple of minor documentation issues, so I've fixed this on both the trunk and the release branch. P.S.3: Going over all the differences I've found a trivial change in the testsuite for value_initialized: The trunk version uses the lightweight "minimal" test tools instead of the full test tools. I've merged this one as well. Can I commit these changes to the release branch? --- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
On 11/11/2010 8:13 AM, Fernando Cacciola wrote:
Hi,
As reported by Eric Niebler, the release brunch did not had the swap member that existed in the trunk for a long time. I just merged it locally and run the tests on the release branch. Can I commit the changes?
No, we're only taking showstopper bug fixes (and documentation tweaks) at this point. But the changes to optional will be gladly welcomed once 1.45 is out the door.
P.S: The test suite changed as well due to the different swap.
P.S.2: I've also been reported on a couple of minor documentation issues, so I've fixed this on both the trunk and the release branch.
Fine.
P.S.3: Going over all the differences I've found a trivial change in the testsuite for value_initialized: The trunk version uses the lightweight "minimal" test tools instead of the full test tools. I've merged this one as well.
This is an oops. Please don't merge anything to release bug showstopper bug fixes and doc tweaks. -- Eric Niebler BoostPro Computing http://www.boostpro.com
Hi Eric, OK, I will wait for after 1.45 to merge these fixes. Thank you -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com
Eric Niebler wrote:
On 11/11/2010 8:13 AM, Fernando Cacciola wrote:
Hi,
As reported by Eric Niebler, the release brunch did not had the swap member that existed in the trunk for a long time. I just merged it locally and run the tests on the release branch. Can I commit the changes?
No, we're only taking showstopper bug fixes (and documentation tweaks) at this point. But the changes to optional will be gladly welcomed once 1.45 is out the door.
P.S: The test suite changed as well due to the different swap.
P.S.2: I've also been reported on a couple of minor documentation issues, so I've fixed this on both the trunk and the release branch.
Fine.
P.S.3: Going over all the differences I've found a trivial change in the testsuite for value_initialized: The trunk version uses the lightweight "minimal" test tools instead of the full test tools. I've merged this one as well.
This is an oops. Please don't merge anything to release bug showstopper bug fixes and doc tweaks.
Oops. I merged some bug fixes yesterday and noticed I forgot to add a header and merged that today to fix compilation failures that showed up in release regressions. The schedule said 1.45 was supposed to be released on the 1st, but I forgot that we pushed it out for show stopper bug fixes. The particular bugs fixed revolve around polygon resizing for general polygons being almost completely broken in the 1.44 release. We have the option of reverting my changes to the release branch or keeping them if release regressions pass. I would prefer to get the issues with resizing fixed in 1.45 since they have already been reported by users of the 1.44 release. Thanks, Luke
On 11/11/2010 11:59 AM, Simonson, Lucanus J wrote:
Eric Niebler wrote:
Please don't merge anything to release bug showstopper bug fixes and doc tweaks.
Oops. I merged some bug fixes yesterday and noticed I forgot to add a header and merged that today to fix compilation failures that showed up in release regressions.
I'm making my I'm-not-happy face right now.
The schedule said 1.45 was supposed to be released on the 1st, but I forgot that we pushed it out for show stopper bug fixes. The particular bugs fixed revolve around polygon resizing for general polygons being almost completely broken in the 1.44 release.
We have the option of reverting my changes to the release branch or keeping them if release regressions pass. I would prefer to get the issues with resizing fixed in 1.45 since they have already been reported by users of the 1.44 release.
Leave it. Please be check the regression logs and notify us if you see anything amiss. This mistake is understandable and all too easy to make. Our process needs to be improved. It can't rely (as it currently does) on library maintainers following the developer list for hold-your-horses and all's-clear messages from the release managers. Suggestions? Can we lock the release branch? Trac is already smart enough to parse commit comments for bug numbers and close tickets. Can we make it smarter to block commits that aren't closing out a showstopper? -- Eric Niebler BoostPro Computing http://www.boostpro.com
Eric Niebler wrote:
This mistake is understandable and all too easy to make. Our process needs to be improved. It can't rely (as it currently does) on library maintainers following the developer list for hold-your-horses and all's-clear messages from the release managers. Suggestions? Can we lock the release branch? Trac is already smart enough to parse commit comments for bug numbers and close tickets. Can we make it smarter to block commits that aren't closing out a showstopper?
Is there a feature of revision control that allows a commit to go into a "pending approval" state where the release manager can review the commit message (or code changes if they feel the need) before allowing a commit to go through? If not then our next best option is probably to lock the release branch and unlock it manually for specific users who have show stopper fixes that they want to commit and ask for permission on the dev list or directly from the release manager. Once the release branch is unlocked for a developer it remains unlocked because it is assumed they know what is going on because they asked for it to be unlocked and that they need it to remain unlocked so that they can address any regression failure caused by bad merges or whatever might go wrong with their commit. Once the release goes out the release branch can be unlocked for everyone until the next code freeze. I wouldn't suggest a smarter solution that automatically detects fixes to showstopper bugs. It just sounds too complicated, which means it could lead to problems like people being confused how to commit their show stopper bug fixes or problems with it breaking when something changes in the future. P.S. my regressions are passing now on the release branch. Regards, Luke
Simonson, Lucanus J wrote:
Eric Niebler wrote:
If not then our next best option is probably to lock the release branch and unlock it manually for specific users who have show stopper fixes that they want to commit and ask for permission on the dev list or directly from the release manager. Once the release branch is unlocked for a developer it remains unlocked because it is assumed they know what is going on because they asked for it to be unlocked and that they need it to remain unlocked so that they can address any regression failure caused by bad merges or whatever might go wrong with their commit. Once the release goes out the release branch can be unlocked for everyone until the next code freeze.
This was suggested and tried soon after SVN was installed. The problem is that SVN took hours to do the lock. For now, I don't think that there is a practical fix for this - other than to just be more careful and recognise that from time to time it will occure. Robert Ramey
Robert Ramey wrote:
Simonson, Lucanus J wrote:
Eric Niebler wrote:
If not then our next best option is probably to lock the release branch and unlock it manually for specific users who have show stopper fixes that they want to commit and ask for permission on the dev list or directly from the release manager. Once the release branch is unlocked for a developer it remains unlocked because it is assumed they know what is going on because they asked for it to be unlocked and that they need it to remain unlocked so that they can address any regression failure caused by bad merges or whatever might go wrong with their commit. Once the release goes out the release branch can be unlocked for everyone until the next code freeze.
This was suggested and tried soon after SVN was installed. The problem is that SVN took hours to do the lock.
It seems that two concepts are confused here. SVN has locking, which allow to lock a specific file or directory to a specific user. It also has permissions, which allow to limit commits to specific directory (such as /branches/release) to specific persons (plural). However, the permissions have to be modified directly on the server -- which I suppose is a logistical problem. - Volodya
On Thu, Nov 11, 2010 at 8:04 PM, Eric Niebler <eric@boostpro.com> wrote:
This mistake is understandable and all too easy to make. Our process needs to be improved. It can't rely (as it currently does) on library maintainers following the developer list for hold-your-horses and all's-clear messages from the release managers. Suggestions? Can we lock the release branch? Trac is already smart enough to parse commit comments for bug numbers and close tickets. Can we make it smarter to block commits that aren't closing out a showstopper?
It's very simple to add a check to the precommit hook that for the release branch mandates that (during the beta period) all commit messages are prefixed with something like "SHOWSTOPPER FIX: ". This way no one will be committing to the release branch by mistake. The error message for the precommit can give all needed information. I.E. tell the committer how to get allowed to commit, and how to prefix the commit messages. The extra test shall be removed when the release branch is opened again. /$
Henrik Sundberg wrote:
On Thu, Nov 11, 2010 at 8:04 PM, Eric Niebler <eric@boostpro.com> wrote:
This mistake is understandable and all too easy to make. Our process needs to be improved. It can't rely (as it currently does) on library maintainers following the developer list for hold-your-horses and all's-clear messages from the release managers. Suggestions? Can we lock the release branch? Trac is already smart enough to parse commit comments for bug numbers and close tickets. Can we make it smarter to block commits that aren't closing out a showstopper?
It's very simple to add a check to the precommit hook that for the release branch mandates that (during the beta period) all commit messages are prefixed with something like "SHOWSTOPPER FIX: ". This way no one will be committing to the release branch by mistake. The error message for the precommit can give all needed information. I.E. tell the committer how to get allowed to commit, and how to prefix the commit messages. The extra test shall be removed when the release branch is opened again.
I like this suggestion. It gets the job done with the least ammount of fuss. Luke
participants (6)
-
Eric Niebler -
Fernando Cacciola -
Henrik Sundberg -
Robert Ramey -
Simonson, Lucanus J -
Vladimir Prus