Boost logo

Boost :

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.

Interesting.

>> 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
cycle?

> 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
them.

-- 
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