Re: [boost] The Release Manager's Point of View (was: Re: Boost Development Environment proposal)

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2007-06-04 15:42:28

"Thomas Witt" <witt_at_[hidden]> wrote in message 
news:f41nhr$u26$1_at_sea.gmane.org...
>
> Hi,
>
> Douglas Gregor wrote:
>> On Jun 4, 2007, at 10:10 AM, Beman Dawes wrote:
>
> I was going to write this email, but Doug beat me to it.
>
> <snip/>
>
>>
>> Look at the 1.34 release series... the thing that's been holding us
>> back most of all is that the testing and test reporting tools are
>> broken. 1.34.1 is stalled because we have failures on one platform,
>> but nobody can see what those failures actually are: the test
>> reporting system removed all of the important information.
>
> From my point of view Doug is spot on. The proposal seems to assume
> infinite resources in testing. The reality is we can not even test one
> branch reliably and this despite considerable effort by a number of
> people. With the current setup the process outlined is unworkable.

What practical steps do you see to increase the test system stability?

> As an example on how bad things are: I would like to merge changes for
> 1.34.1 one at a time so that I can identify the change that broke
> something. With the current turn-around time, even when the system works
> as designed, this is impossible unless we aim for a X-mas release date.

IMO, this is not a responsibility of release manger *whatsoever*. Release 
manager have to release only the staff that is already tested. No testing, 
no merging. If I want my changes to be released I will invest time into 
making sure they passed all the tests.

>> I agree with most of Beman's write-up, but it pre-supposes a robust
>> testing system for Boost that just doesn't exist. I hypothesize that
>> the vast majority of the problems with our release process would go
>> away without a single change to our process, if only we had a robust
>> testing system.

The robustness of the testing system will increase marginally as soon no one 
will be able to break someone else without explicit permision from that 
someone.

> Agreed. Lets build the foundations first.
>
>> We have only so much volunteer time we can spend.
>
> <rant>
>
> It always strikes me as odd that we spend many man-hours discussing the
> process while we are spending very little on fixing bugs. In my
> experience the man-hours available for bug-fixing are severely limited.
> I want to explicitly exclude Beman here. He fixed the outstanding bugs
> _and_ spend the time for the paper. This is not the norm so.

No one can enforce developers to make volontir work. IMO the system should 
not depend on any particular developer schedule. There is always stable 
version of this particular component others can depend on.

> </rant>
>
>
>> At
>> this point, I think our best bet is to spend it making the regression
>> testing infrastructure work well; then we can move on to a new
>> process with its new tools.
>
> From my experience this is the only promising way forward. You can also
> rephrase it as: "Let's stabilize something, before we destabilize
> everything.". We will not ship 1.35.0 within the next year if we do
> major surgery to our directory structure. It's just not going to happen.

I would  not be that pessimistic. Directory restructuring is simple enough 
with snv. What are the problems you invision?

> I strongly urge us to do something simple and restricted in scope first.
> That will give the biggest bang for the buck.

The problem is to decide on what is simple and how will it help. Do you have 
soomething specific in mind?

Gennadiy