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