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
Rene Rivera wrote:
* 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.
Interesting. The moderators just had a chat about the release process, and we agreed that having multiple release managers working together to get releases out the door would be a good idea. We were talking about two rather than three people, but I can see the logic in having three. - Doug
________________________________ From: boost-bounces@lists.boost.org on behalf of Rene Rivera Sent: Fri 07/09/2007 08:52 To: boost@lists.boost.org Subject: [boost] Release Team?
[HUGE snip.] * A release team is composed of three people.
So that would be you, Voloyda (sp?) [he did a lot of visible work pushing 1.34 out the door], and Thomas [he has the scars^H^H^H^H^H experience of actually being a release manager]. Sounds an excellent scheme to me. -- Martin Bonner
Rene Rivera wrote:
* Being a release manager is a lot of work because of the size and scope of Boost.
...
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:
The short form of the above is - Its a bigger job than it used to be - we need more people. In my opinion this is 180 degrees in the wrong direction. It will make things worse rather than better. The right way to think about this is: Its a bigger job than it used to be - Divide into smaller jobs. This means just adding one tested library at a time. So the next release should be the 1.34.1 release with just the stuff that's has been proved to be ready now. As far as I can see, the only library that meets this criteria is Joaquin's Multi-Index which has been tested against 1.34.1 and is currently available as a separate upgrade to 1.34.1. If you can find Three people who want to be release manager, then line 'em up and give them 1.34.2, 1.34.3 and 1.34.4. Now someone is going to say - that's too hard - You're tripling the work !!! Ahhhh - and why is that? That's because the build/release system is waaaaay to fragil. I'm still having problems with in spite of spending significant amount of time to make this thing work. Boost Build has to be packaged as a separately testable component that can be subjected to the same kind of offline testing that the libraries are subjected to. Basically, the whole release process is serving as a debugging procedure for Boost Build. This make creating a release hard. Soooooo, to summarize, a) Move to incremental releases b) Formalize the developement of Boost Build to the standards demanded of other boost components. Robert Ramey
Robert Ramey wrote:
Rene Rivera wrote:
* Being a release manager is a lot of work because of the size and scope of Boost.
...
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:
The short form of the above is - Its a bigger job than it used to be - we need more people.
In my opinion this is 180 degrees in the wrong direction. It will make things worse rather than better.
I think you can view this from a different angle. There's, say, 20 people participating in discussion about release process. That's like, 20 release managers. Each one has different background, different experience with release making, version control, testing, and tools, so it's not likely that any consensus will arise any time soon. One ideal solution is to get a release manager, who will just decide on minor details of the process. However, nobody's signing up for this job. So another solution is to have several people.
If you can find Three people who want to be release manager, then line 'em up and give them 1.34.2, 1.34.3 and 1.34.4.
Now someone is going to say - that's too hard - You're tripling the work !!!
Ahhhh - and why is that? That's because the build/release system is waaaaay to fragil.
I think you'd more effectively get your point across by using conventional spelling.
I'm still having problems with in spite of spending significant amount of time to make this thing work.
I do agree that you post a fair number of Boost.Build questions. I don't know why it's so problematic for you, specifically, and I don't remember any unresolved questions.
Boost Build has to be packaged as a separately testable component that can be subjected to the same kind of offline testing that the libraries are subjected to.
"Offline testing"? What's that? You surely know that Boost.Build has a comprehensive test suite?
Basically, the whole release process is serving as a debugging procedure for Boost Build. This make creating a release hard.
This is your personal opinion; mine is that the calendar time spent on fixing Boost.Build issues is not the biggest contributor to 1.34 release process time. - Volodya
Robert Ramey wrote:
Rene Rivera wrote:
* Being a release manager is a lot of work because of the size and scope of Boost.
...
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:
The short form of the above is - Its a bigger job than it used to be - we need more people.
The short form is - It will be a bigger job, on average, with each release as more "components" are added to Boost.
In my opinion this is 180 degrees in the wrong direction. It will make things worse rather than better.
Worse how?
The right way to think about this is: Its a bigger job than it used to be - Divide into smaller jobs. This means just adding one tested library at a time.
That would only partially reduce the work. What about bug fixes to existing libraries? What about added platforms? What about improvements to release tools? What about release packaging? What about bug/issue monitoring? What about release documentation? ...and so on for all the things a release manager does. [...]
If you can find Three people who want to be release manager, then line 'em up and give them 1.34.2, 1.34.3 and 1.34.4.
I suspect we will never have volunteers given the specter of facing what Thomas went through alone.
Now someone is going to say - that's too hard - You're tripling the work !!!
Yes.
Ahhhh - and why is that? That's because the build/release system is waaaaay to fragil.
Do you expect the entire release system to be fixed before we do another release? [...]
Soooooo, to summarize,
a) Move to incremental releases
Yes. Which is what Beman and yourself, and everyone else AFAICT, is saying. Do you have some other definition of "incremental"? How are incremental releases different from previous releases?
b) Formalize the developement of Boost Build to the standards demanded of other boost components.
Yes, and IMHO Boost Build V2 is of higher quality than some Boost libraries. But perhaps you mean the development of release and testing, tools and procedures? -- -- 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
Rene Rivera wrote:
The short form is - It will be a bigger job, on average, with each release as more "components" are added to Boost.
In my opinion this is 180 degrees in the wrong direction. It will make things worse rather than better.
Worse how?
By trying to do more things at once rather than less.
The right way to think about this is: Its a bigger job than it used to be - Divide into smaller jobs. This means just adding one tested library at a time.
That would only partially reduce the work. What about bug fixes to existing libraries? What about added platforms? What about improvements to release tools? What about release packaging? What about bug/issue monitoring? What about release documentation? ...and so on for all the things a release manager does.
We've been through all this. each of these things should be tested against the latest "ready to release". Each time a developert things its ready, that one set of changes is rolled into the ready to release and a tarball is made for release testing. I that passes, its made availble to users.
I suspect we will never have volunteers given the specter of facing what Thomas went through
100% agree
Now someone is going to say - that's too hard - You're tripling the work !!!
Yes.
LOL - I knew it.
Ahhhh - and why is that? That's because the build/release system is waaaaay to fragil.
Do you expect the entire release system to be fixed before we do another release?
I don't expect a release to have a release system that needs fixing. I expect a release system which works advertised - even if it doesn't have every feature that everyone wants. Then I expect the release system - like any other boost component - to be incrementally improved by the addition of useful features. I expect the release system - like I expect of any other boost component to always work - even though its never finished. In fact, I expect even more than that. I expect every boost component to be shipped with a way of verifying on the target machine that it does in fact work the way its documented to work.
a) Move to incremental releases
Yes. Which is what Beman and yourself, and everyone else AFAICT, is saying. Do you have some other definition of "incremental"? How are incremental releases different from previous releases?
Ahhhhh - maybe that's the source of some confusion. The whole concept of a "Boost Release" contains in its name that at a certain point in time, every thing synced up at exactly the same moment. I don't that's possible. What I want is: a) A release ready branch which hasn't had anything checked into it which hasn't been proved to work. b) A simple reliable way to make tarball from the release ready branch which an be run every time a component has been checked in and the branch re-tested. c) A test of the branch whenever something is checked in. d) To make any tarball which passes the final test available to the public. e) I want the same steps above applied to every boost component which is fixed/improved or enhanced. f) I DON'T want separate bug fix releases, bug fix branches, etc. In short - there should be no distinction between incremental release and previous releases. In practical terms I would expect a new tarball available to the public every few weeks.
b) Formalize the developement of Boost Build to the standards demanded of other boost components.
Yes, and IMHO Boost Build V2 is of higher quality than some Boost libraries. But perhaps you mean the development of release and testing, tools and procedures?
Here is my example. I didn't keep notes so I just speaking from memory. a)I get SVN on my machine and become more or less comfortable with it. b) I create a branch on RC_1_34_1 and check it out to my machine. c) I merge in the changes to the serialization library which have accumulated during the 1 1/2 years while 1.34.1 has been "in release" d) I re-run the tests for the serialization library. OK a few problems with new bjam.v2 syntax. Now I have a big problem with bjam syntax but we're not going into that right now. e) Now I have no way of seeing the results. The original compiler_status nor me compiler_status2 don't work anymore due to changes in bjam, toolset jamfiles and process_jam_log. This combination is fragil due in large part that there is no documented interface for passing data from one component to the other. Well, I get the squared away - at least on my machine. f) Now I run all my old platforms. STLport jam files don't work - This is from the release platform!!!. Commeau does't work no information on how to fix this. The directory structure has been shuffled around so anything I had before such as a VC IDE solution won't work anymore. I big thing for me was to be able to use the profile build variant. Well this "sort of" works with gcc. Whe I ask about this, i'm told that no one has ever asked about it before and anyway profiling isn't considered effect for C++ programs !!! I would be inclined to fix it - but the whole bjam langauge/tools setup is very hard to understand so its too risky to mess with. I just make a shell script which walks the directory tree and re-executest all the tests - about 20 lines of shell script. That's the short version - I forgot the rest. So it takes a huge amount of work and only just now getting to the point that I was before 1.34 came out. To a man with a hammer in his hand, the whole world looks like a nail. To a group of software library/tool programmers, every problem looks like it will be solved with a new tool. Generals (and politicians - and actually everyone) have the tendency to re-fight the last war. That's what we're currently doing here. Robert Ramey
on Fri Sep 07 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Robert Ramey wrote:
Rene Rivera wrote:
* Being a release manager is a lot of work because of the size and scope of Boost.
...
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:
The short form of the above is - Its a bigger job than it used to be - we need more people.
The short form is - It will be a bigger job, on average, with each release as more "components" are added to Boost.
Part of the reason the moderators have been discussing this in private is that Boost as a community has been debating our next steps for months now, and we're not getting any closer to consensus. We need to get Boost development moving again. Never making a decision about process would be worse than choosing *any* of the possible plans being discussed. We (the moderators) are almost ready to post the plans with which Boost will be moving forward. This should not be construed as an endorsement or condemnation of anything being discussed here on the list; it's just a report about what's coming. Cheers, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Rene Rivera wrote:
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.
As Doug mentioned, the moderators have also been discussing a team approach to release management. I'd like to see perhaps three people take on the job of "Release Management", but with one of then still designated as "Release Manager" so that there is a single point of final authority. Beyond that, I'd like to see some specific sub-tasks delegated to several additional small teams. For example: * Test team. Keep the tests running smoothly and in a timely manner. * Procedures team. Refined development and release procedures and the documentation that communicates them. * Web site team. Responsible for web site pages other than those for specific libraries. * Docs team. This one's already up and running! * Quality team. Work on procedures and scripts to ensure releases are complete and correct. Those are just quick thoughts and would certainly evolve over time. The exact breakdown doesn't really matter. The key point, however, is that responsibility and authority is delegated so that progress can be made in parallel and asynchronously. --Beman
participants (7)
-
Beman Dawes -
David Abrahams -
Douglas Gregor -
Martin Bonner -
Rene Rivera -
Robert Ramey -
Vladimir Prus