Re: [boost] [SVN]Best Practices for developers using SVN

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-03 11:40:42

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 -- regressions are trivially convertible 
into bugs in a bug tracker; and clearly regressions must be tracked 
somehow. 

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.
        3. Having to time window for fixing.

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.

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

- Volodya