Re: [boost] The Release Manager's Point of View

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-06-06 22:35:20

Thomas Witt wrote:

>... The proposal seems to assume infinite resources in testing.

I must not have been clear. The proposal would do much less testing than 
is currently done. Under the current scheme, testing is done even when 
no one requests a test for a particular library and compiler. Under the 
proposal, tests only get run when someone requests a test. So for 
example, a Windows developer would only likely request tests on 
non-Windows platforms.

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

Yes, of course. The current testing setup (where unstable code is 
allowed to be committed to the release branch) is hopeless and should be 
abandoned.

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

Yes, that's why I'm saying we need to abandon the shotgun approach to 
testing everything that causes the long turnaround times.

> 
> <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.
> 
> </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 disagree. As long as we start from a release (presumably 1.34.1) as 
the stable branch, and only allow known-good changes to it, it should 
always be ready to ship. Period. When the agree upon ship date arrives, 
changes to any libraries that didn't make it into the release just have 
to wait until the next release.

Changes to the directory structure (and anything else) are done on a 
library-by-library basis. So such big changes take several release 
cycles to roll out. That's all.

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

We need to change to Subversion so we can get better repository control. 
We need to begin the next release from the last release, and not apply 
changes to the release branch unless they are known good. I see those 
changes as "simple and restricted in scope".

I'd also like to see one or two small libraries change their directory 
structure, so we can verify that the new structure works in practice 
before we start changing directory structures for all libraries.

--Beman