From: Thomas Witt (witt_at_[hidden])
Date: 2007-08-03 15:17:21
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.
Any approach that relies on people doing things when asked is doomed.
> 1. Document the process.
> 2. Distribute it in time -- for example if we have
> a single 'development' branch, we can record all regressions
> that appear on the branch and demand that they are fixed
> in a month, or the offending commit reverted.
> 3. Distribute it over people -- instead of having
> one release manager doing all the work, we can have
> "bug masters" that will focus on regressions in a
> subset of platforms, or subset of libraries.
There were many documented and distributed processes in the past. Nobody reads the FM. And
to be honest I can't even blame people.
-- Thomas Witt witt_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk