Re: [boost] Proposal for radically altered approach to releases

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-12 23:13:04

Beman Dawes wrote:
> The current approach to getting releases ready is completely broken in 
> my opinion. Each release requires heroic efforts by the release manager, 
> careful attention by many developers, and endless delays until 
> everything is just right.

No doubt that the process is broken.  I will say though, part of the 
problem has always been nicely waiting for fixes to be made.  Releases 
could trivially be made by reverting any library with regressions to the 
version in the previous build.  This is similar to what you are 
proposing, but would be more on the shoulders of the release manager to 
be ruthless about meeting the deadlines.  The current release, for 
example, would be progressing much faster if we just took the obvious 
position: v2 build system isn't stable enough, revert to v1 and move on. 
v2 will be in the next release.

> This is discouraging to developers and, worse yet, important library 
> upgrades and bug fixes are taking far too long to get into user's hands.
> 
> The problems with the current release approach are not caused by release 
> managers or developers, but rather by the release system itself. It just 
> doesn't scale up to the number of libraries now in Boost, since every 
> library has to be ready before a release can occur.

Again, it's mostly because the release managers are too nice.  I'll 
volunteer to be the next release manager, I'll set a date, and I'll 
pretty much assure you that it will go out on or about that date because 
I'd cut any change off that wasn't ready.  One really good thing about 
your proposal is that it builds in the fix it or you're reverted 
expectation that has been lacking for so long.

> These problems will only grow worse as more libraries are added.
> 
> I propose changing to a different release model, one based on always 
> maintaining a release-ready stable branch and merging updates for 
> individual libraries into it asynchronously.
> 
> A draft proposal is available at 
> http://mysite.verizon.net/beman/release_overview.html.
> 
> I've put a fair amount of thought into this proposal, and have run some 
> Subversion simulations to make sure it works smoothly.
> 
> What do others think?

In general I like the direction.  A couple concerns though:

1) This does mean additional work for developers since all changes will 
require merges.  So this better be really easy to do in SVN for the 
trivial merges for an entire library.  I still don't use SVN on a daily 
basis, so it is hard for me to evaluate how much work merging will 
require.  Overall, however, it will be worth a little extra work to make 
the release process actually work again...

I also wonder if there should be exceptions to this policy.  For 
example, a documentation update or example code not compiled as part of 
regression test update.  Putting these on the trunk will not provide any 
feedback anyway.  The only danger is that if you allow these exceptions 
someone might get sloppy.

2) The dynamics of past releases have shown over and over that as good 
as the regression system is unexpected things show up.  So we either 
need to tag a point where minor changes can be made to a release stable 
point or freeze major changes on stable for a beta period while 
beta-testers go one last step and test the packaged release.  This is 
mostly to avoid having to redo release notes, version numbers and other 
work associated with the release.

3) Some core libraries need to be mercilessly reverted on the trunk as 
well as on stable.  There is a core set of libraries that cause major 
issues when they don't work.  type traits, config, and test come to 
mind.  If these libraries are unstable on the trunk they prevent other 
developers from validating and moving their code to stable.  Thus 
developers of these libraries will need to be held to a higher standard 
than developers of other libraries.  They need to revert changes on the 
trunk after some pre-defined period (48 hours maybe) if they can't fix a 
build issue that is breaking lots of other libraries.

4) I suggest that the set of compilers monitored on the stable branch 
will only be the group of agreed "supported compilers".  If volunteers 
want to add a new compiler to the supported set (say some new version of 
the Sun compiler) they must demonstrate that a previous stable build of 
Boost passes all libraries with no unmarked failures.  It is up to these 
volunteers to work with developers to achieve this state using the trunk.

Thx for doing this Beman -- it's something that really needs to be tackled.

Jeff

-----
Minor wording nits:

     * Regression tests are run daily on both trunk and  stable. Testers 
coordinate via the boost-test mailing list to ensure that both truck and
                                                                ^^^^^
       Note well: Reverting is a safety-value only. Developers must never
                                 ^^^^^^^^^^^^