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