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