Thomas Witt wrote:
Volodya,
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 been defined. The current task of the Release Manager is to get out a boost quality release. In 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. Robert Ramey