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

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-09-02 15:46:14

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