David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
