From: David Abrahams (dave_at_[hidden])
Date: 2007-08-04 21:51:56
on Fri Aug 03 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
> David Abrahams wrote:
>> on Thu Aug 02 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
>>> there's one bit where out process is not broken, it's
>>> nonexistent. The important aspect of Boost is that we have lots of
>>> automated tests, or lots of different configurations and there's
>>> the goal of no regressions. This is a very strict goal.
>>> At the same time we don't have any equally strict, or even written
>>> down bug-triage-and-developer-pinging process.
>> I agree that we could improve in that area, but it doesn't have
>> much to do with our long release cycle.
> I think it's one of the primary problem causing long release cycle.
>> The bugs that held up our last release showed up in our regression
>> tests, not in our bug tracker.
> This difference is not important --
Okay... well, developer pinging can and should be automated. We
already have a "strict" mechanism for it in place. Maybe it could be
better; I don't know.
What kind of bug triage process do you think we should have?
> regressions are trivially convertible into bugs in a bug tracker;
> and clearly regressions must be tracked somehow.
I guess the problem is that such conversions are hard to effectively
automate. One mistake in a library could turn into 50 test failures;
if they all look the same, you'd probably only want one ticket.
> And long release cycle is direct result of:
> 1. Wanting zero regressions.
> 2. Library authors sometimes being not available, and
> there being no pinging process.
There certainly is a pinging process. Don't you get the "there are
bugs in one or more libraries you maintain" messages?
> 3. Having to time window for fixing.
Do you mean http://article.gmane.org/gmane.comp.lib.boost.devel/158259
? If not, what is a "time window" and how would a time window help?
> So we end up with a regression and all we know there's a regression.
> We do not know if this issue is being worked on, or if the library
> author will have time only in N days, or if the library author
> needs help from platform expert (which will have time only in N days).
> The library author, in turn, might have little motivation fixing
> a single regression on obscure platform, if he feels that there
> are 100 other regressions that are not worked on.
It's a plausible scenario that probably happens sometimes, but do you
have any evidence at all that it's at the heart of the long release
> 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
> 1. Document the process.
I guess that would be helpful, since you seem to have some ideas that
differ from what we've been doing, but haven't been specific about
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk