From: Robert Ramey (ramey_at_[hidden])
Date: 2007-08-03 18:01:16
Thomas Witt wrote:
> Vladimir Prus wrote:
>> David Abrahams wrote:
>>> on Thu Aug 02 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
>> We actually had examples of such proactive release management in
>> past, and it worked good, but it's clearly time consuming. So one
>> possible solution is to
> For one thing it does not scale. The more important part that you are
> missing is:
> We have zero leverage over library developers.
> Let me repeat this:
> We have ZERO LEVERAGE over library developers.
you have no leverage because of the way the task of Release Manager has
The current task of the Release Manager is to get out a boost quality
order to accomplish this task he has to do a lot ot stuff.
Under Beman's proposal, the task of Release Manager will
change in a subtle but important way.
One starts with a boost quality release - 1.34.0
The job of the release manager is to only allow merges into the
next release which have been demonstrated to yield an improvement.
Its up to the developer to provide the tests and test runs which
prove that his next "oeuvre" is up to snuff. If the developer
makes his case, the "Release Manager" lets the developer
merge in his changes an run the final tests. I he approves it
pushes the button which makes the tarballs, etc.
BTW - I think this change is a done deal. First I don't think
anyone will volunteer to manage the next release given the
amount of effort you had to invest. Second, even if someone
does, given the increase in libraries and the current state
of the trunk, I think the job will take too much time to finish
and even if it gets finished, will be so late as to be irrelevant.
Of course that's just my uninformed opinion. As I have
never managed the release of a large open source project
myself I'm perhaps overly intimidated by such a prospect.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk