|
Boost : |
From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-09-07 16:30:08
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk