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

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

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:

a) A library author presents argument/evidence that his changes in the
trunk or in a private branch will not break anything in the next release.

b) The release manager evaluates the request and either accepts it
or rejects it with an explanation or counter request for more testing or
whatever.

c) If its accepted, the release manager merges the authors changes
from whereever they have been checked in, maybe runs some
library specific test on his own.

d) The release manager then generates the tarball and uploads it
the designated area and request full testing on it.

e) If the testing results show an improvement over the current
version, anouncement is made and the latest tarball is designated
the most recent official release.

f) The release manager has the descretion to bundle more than
one set of changes in  a release.  He might want to do this to
save time if the changes are ready at the same time and he
sees them as unlikely to conflict.

I order to accomplish a) above with the current tool setup, The
following kind of process is envisioned.

i) The developer keeps a copy of the next release on his machine.
ii) He switches the directories corresponding to his library over
to the place where he has checked in his changes.  This might
be the trunk or a private release branch.
iii) He runs local tests.  I've created library_status with this purpose
in mind.
iv) If he's satisfied and want's help testing on other platforms.  He
finds a willing collaborator to do the test same test on HIS platform.
Note that this testing is quite fast as its only one library.  Personally
I would recommend that this testing be for all likely build variations
<variant>build/release, <link>static,shared, <threading>multi,single
The tester can report the results back to the author.  Currently
there is no documented way to do this conveniently.  But I feel this
could be done with little effort.  Again I created library_status to
permit browsing of the accumulated results in a convenient manner.

> 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.

>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

>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.

> 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.  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.

***
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

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

Robert Ramey