[boost] Release Team?

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-09-07 03:52:53

Just catching up after a week vacation... I had a quick conversation on 
IRC with Volodya where he mentioned a rather appealing idea which 
happened to coincide with a similar idea I was having. He mentioned the 
idea of a "release team" to hammer out the specifics of the new release 
procedures.

Now what I was thinking of... For a while now I've been considering 
volunteering to manage a release. But I came to some obvious 
observations, and others pointed out similar thoughts:

   * Being a release manager is a lot of work because of the size and 
scope of Boost.

   * There's a lot of learning involved for each new manager. In the 
form of learning the process and tools to get the release completed.

   * It seems we are expecting the manager to both manage releases, and 
to advance the development of the release procedures. This is not new to 
this release cycle. AFAICT most release managers have "fine tuned" the 
release process as part of their work.

   * If we are going to expect another Boost release, with something 
more than just patches, in the near future we have to start a release 
cycle now.

   * As a body of volunteers, no one person has enough "free time" to 
devote to managing a release. Particularly if that same person is also 
dealing with development of a Boost component.

For 1.35 the release manager is going to face not just fine tuning the 
process, but overhauling it. The repository changed, the process is 
changing, and the tools are changing. Additionally, from my POV, the 
discussions about the new release process don't seem to be progressing 
at a quick enough pace. This made me realize it would be unrealistic for 
me to devote the need time that being a release manager would require. 
So the simple idea is to have a "Release Team" instead of a "Release 
Manager" to distribute the work and hopefully smooth out the attention a 
release gets. The dynamic would be:

   * A release team is composed of three people. Yes, it's an arbitrary 
number, hence it only feels right because of the expected amount of work 
1.35 is likely to be. For later releases two people might be enough.

   * The goal is for the team to have a good spread in understanding of 
the release process. And hence we should prefer picking, when possible, 
people with knowledge of the management, building, and testing aspects 
of the process.

   * The members of the team are free to decide how they split up the 
work. But we should encourage working on all aspects to advance the 
spread of the release process know-how.

   * A member signs on for two consecutive releases, in a staggered 
order. The obvious exception being the first few releases where one or 
more would only do one release. This reduces the ramping up time a 
single release manager would go through, hence keeping the releases 
going smoothly.

Does this sounds like an idea worth pursuing, i.e. running with for this 
release? Seeing as we really need to get moving on some process 
decisions if we want to see a release for 2008/01!

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo