[boost] Re: Boost 1.31 release?

From: David Abrahams (dave_at_[hidden])
Date: 2003-08-12 08:01:34

Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:

> Beman Dawes wrote:
>> At 07:37 AM 8/11/2003, David Abrahams wrote:
>>  >Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:
>>  >
>>  >> Beman Dawes wrote:
>>  >>> Assuming I'm release manager for 1.31.0, I'm going to publish
> explicit
>>  >>> release criteria for key platform/compiler pairs. Basically, the
>>  >>> criteria will be 100% accounting for all failures on those
>>  >>> platform/compiler pairs.
>>  >>
>>  >> While I totally support the failures markup goal, I would like to see
>>  >> _the_ release criteria to include "no regressions from the previous
>>  >> release" item as well, preferrably for all non-beta compilers that are
>>  >> currently under regression testing. Especially since now we have tools
>>  >> to ensure it.
>>  >
>>  >I worry a little about requiring library authors not to regress on
>>  >compiler combinations they don't test with.  For example, who is going
>>  >to address the one lexical_cast failure that's plaguing the 1.30.2
>>  >release?  It's only on intel-7.1 with STLPort and looks for all the
>>  >world like a config problem.
>>
>> It can be very time consuming to track down the exact reason for failures.
>> Thus we should focus our 1.31.0 effort on a small number of widely used
>> compilers which don't have a lot of problems.
>
> It doesn't have to be the release manager who investigates all the issues
> himself, though. There might be enough of the interested parties with
> motivation/resources to resolve most of these in a reasonable time frame
> if they a given a chance/"managed" properly.

I am especially concerned about the toll it takes on a release
manager to "give them a chance/manage them".  Managing a release, as
I've recently discovered, is not a piece of cake.  It will suck up at
least a couple of days of someone's time.  Asking the release manager
to (attempt to) track someone down to handle each failure on such a
wide variety of platforms/compilers may not be reasonable.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com