Re: [boost] Re: Boost 1.31 release?

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-08-12 06:22:26

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.  

Well, the regressions are run daily, so testing happens. Another
question is whether library authors care about how their libraries perform
on all the compilers the regressions are being run on.

Obviously, some compilers/configurations are included in the regression
testing because the ones who manage the latter are the ones who are 
most interested in those. Then, again, obviously, some compilers/
configurations are included in the regressions because they are very 
widely used.

For every release, the interested parties include library authors, 
regression runners, the release manager, the maintenance wizard, and of 
course active users who are subscribed to either of the lists.

Given the above "setup", the implied interests of the participating 
groups, and their explicit and implicit responsibilities and gratitude
towards each other, I think striving for "no regressions" goal I stated 
above would be both a reasonable and fair strategy which can be made to
work.

> For example, who is going
> to address the one lexical_cast failure that's plaguing the 1.30.2
> release?  

If I were a release manager, I would:

 1) ask the library maintainer if he is interested in looking at the 
 failure; if he is not, or he is not responding - which is kind of likely
 in this case since Intel+STLPort is not a very common configuration, 
 then:
 
 2) ask the regression maintainers to look at the failure; if they are 
 busy/don't know how to fix it, then:
 
 3) put the issue on the list of probable regressions, and in at least 
 a week before the release post an explicit pre-release regression warning
 on possibly both the users and developers lists asking interested parties
 to step in; if nothing happens, release with the regression and document
 it in the release notes.

In this particular case, you can assume that we are at the stage 2.

> It's only on intel-7.1 with STLPort and looks for all the
> world like a config problem.

Well, then we'll take a look at it closely.

Aleksey