Re: [boost] Updated Development and Release Practices for 1.35.0

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-09-02 12:35:38

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