Robert Ramey wrote:
Vladimir Prus wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything. Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still?
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. As written, such merge is just disallowed.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree.
At the option of the release manager, the changes are rolled back or the bug is fixed in the release-ready tree.
Sorry, what bug? There's no bug at this point yet.
Week later, a serious bug is found in another library. Is there a place where that bug can be fixed?
If the bug is found in the release ready tree, the release manager has the same two alternatives described about. Ask for fix or roll back. It's up to him
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. 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. Clearly, asking the author of XXX to revert his changes is wrong -- he followed every policy.
Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
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.
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?
The difference is that it would only need be done when requested by the release manager after he has merged something in.
Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or
(2) be made on release-ready tree directly.
I would not expect the release manager to approve this and merge in such changes unless they are of a very small and/or trivial nature. He will have to weigh the risk as he's stuck with the consequences.
(1) requires on-demand testing of branches. Is (2) the way to go?
Yes it is. For now we can just do it in the informal/ad-hoc way described above. Assuming it works out, this process can be made more automated.
Concerning (1), your definition of release ready will prevent merge if there even a single regression.
Generally this is true. The release manager would have the option of making a change in the release-ready branch.
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.
*** 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?
This could/include
a) Joaquins Multi-index which he claims to have tested against 1.34.1
b) build system corrections/improvements
c) Any other libraries whose authors want to submit evidence that their recent changes haven't broken anything.
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. - Volodya