Vladimir Prus wrote:
Robert Ramey wrote:
I think this is something the the Release Manager and only the Release Manager should do. Although the most convenient way to do this is still the subject of experimentation I would envision the following:
Well, "Release Manager decides" is an acceptable policy, but then we need to leave this option option in the guidelines.
Agreed.
Roll back what? Let the try again. 1.35 is released *already*, and then release branch has a big change in library XXX -- performed with all the procedures.
I assume that "release branch" means 1.36 at this point.
Now there's a bug in library YYY, and the author has a one-line fix ready. If that fix is committed to release branch, we have a version of Boost with one small fix, and big change, so it's now not a safe upgrade for users.
Assuming both changes have followed procedures its no different than anything other change.
Clearly, asking the author of XXX to revert his changes is wrong -- he followed every policy.
Agreed that should never happen and I see no situation where that would
Release-ready tree already has source-incompatible change to other library?
How so? if both changes have been subjected to the same procedure, the release-ready tree is still release ready.
In other words -- from which tree is 1.35.1 going to
be released?
The release-ready tree - as always. It will contain at least two changes. One large change on library XXX and one small bug fix on library XXX. Depending on the judgment of the release manager, it might contain other changes as well.
Release 1.35.1 is released when the released manager feels that its a significant improvement over the previous release. He has the authority to merge in changes and rollback.
I think it's very hard for release manager to predict what kind of bugs will be discovered. So, there's always the change that a big change is followed by a small bugfix, leaving a tree that might be too early for new release, but already not suitable as bug-fix release.
My view can be summarized as follows: All changes are added and tested one (or a small number) at a time. If it fails release test then either a fix is made or the change is rolled back. But the fixed point is that the release-branch is always "release-able" except for the tiny amount of time while the release manager is deciding whether a failed test should imply a fix or a roll back. While this thought process is occurring, (maybe a day?). The release branch is temporarily blocked and not releaseale. Other changes are not rolled in until the current situation is resolved and the release branch is releaseable again.
3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree?
Similar to the testing which has been done on the release candidate in the past.
Erm, that is, announce RC and then wait for comments? No formal testing?
As each change is merged into the release ready branch, the release manager would request testing on this branch. Meanwhile he doesn't make any changes on this branch. After he has enough test results and the results indicate and improvement over the current release, it make the same tarball that has been tested the "official" one that users download.
The occurence of this situation signals a like interface-breaking change so rolling back might seem drastic, but its likely that the change has larger implications that one test failure shows. So if I were release manager, I would be predisposed to just punting back to the library author(s) to address.
So, obscure version of obscure compiler can block all progress.
A change which breaks an interface which other components depend upon means that change can't be merged in. It blocks progress on that component. If through oversight, such a component is merged into the release-ready branch and this oversight is discovered during release tarball testing, the component has to be rolled out while the component author and its users reach some sort of consensus. In the mean time, progress on that component (and only that component is stalled. Under the current system, such a breaking change breaks a lot of other stuff and blocks progress on all the stuff it breaks. for an "obscure version of obscure compiler" the release manager could let in the change anyway. The criteria for a release is not perfection. The criteria is a "measureable improvement over the current release"
As a "test" of this new procedure, I think we should try it with 1.34.2.
This would be targeted for 15 October 2007
I can't parse your "would". Is it -- "this would be targeted, ... if", or "it can be targeted", or "it will be targeted". IOW, are you just proposing this date, or is it set somewhere already?
LOL - I'm proposing the following. Somehow a release manager be selected His task will be to a) create branch for the 1.34.2 release b) merge in ehancements according to the above procedure c) thereby maintain a release-ready branch d) his goal will to be able to make available to the public a tarball for version 1.34.2 on or before 15 October 2007 e) the above suggests to me that he would stop merging in changes on or before 8 October - but of course that would be his decision. Of course someone will loudly complain that its too soon for HIS changes or that he was ready but they couldn't be tested soon enough or that his changes got rolled back because of a trivial to fix bug. Such behavior a person will automatically make himself elgible to be the manager of the NEXT release.
The only question would be the recruitment of the release manager - LOL
Clearly, an email in a thread with 50 emails is not a best way to recruit a release manager. I don't see any evidence a release manager is being sought.
I have no idea how a release manager gets selected. Or by whom. Clearly I'm arguing for a different role for the release manager than he has had in the past. In large part I'm inspired by what I see as the success of the "review manager" in the context of a library. The review manager has a clearly defined responsability and requisite authority to make an important decision. I attribute to this (unique) system boost's singular success. I'm arguing that the Release manager have analagous responsability and authority in the area of admiting changes to the release. Robert Ramey