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 don't need to repeat this twice, and I'm not missing this. This is common in open source. For example, the gcc release manager has no leverage over large majority of gcc developers. Yet, gcc release process where periodic status updates are posted, and where specific persons are pinged to fix specific critical issues works. And much more efficiently than waiting for bugs to disappear.
Any approach that relies on people doing things when asked is doomed.
We actually had some experience ourself. In particular, I think the release managed by Aleksey Gurtovoy (1.32.*) had such proactive approach, and if I remember correctly, it worked good. I think 1.33.*, managed by Doug Gregor was also more proactive. - Volodya