From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-02-09 04:45:27
Vladimir Prus ha escrito:
> This is the summary of regression results as I see it:
> 0. The regression framework seems OK.
> It's also more reliable now --
> thanks to Aleksey, who made XSLT processing more strict,
> and fixed process_jam_log not to loose some output.
> 1. We have a number of regressions with intel-linux-9.0.
> They come from two runners -- Martin and Sandia.
> In Martin's result most failures are due to an command line option
> that intel-9.0 does not understand, and Martin's results
> were not updated since I've checked in the fix.
> Sandia's results are post fix, and I see no linker errors.
> There are some failures that look genuine.
> 2. We have a large number of regression with msvc-stlport
> configurations. Most are linker errors, which suggests
> misconfiguration or Boost.Build bug, or both. I'll work
> with Roland on a solution.
> 3. There are some fails that look genuine.
> I think the right way to get 1.34 released now, as far
> as regression tests are concerned is this:
> 1. Completely freeze the list of tested compilers. This
> means that anything not tested now is not tested. Notably,
> we'll have no coverage for mingw or cygwin versions of gcc.
> 2. Have me and Roland fix stlport issues.
> 3. Start pinging developers about remaining failures. I think
> we should adopt a policy that will guarantee that all failures
> be resolved in a reasonable time -- namely, if a failure is not
> fixed by a certain date, it's marked expected and we move on.
> That cut-off date might be two weeks from the next Monday
> -- Feb 26.
> Both (1) and (3) will certainly have an effect on release quality
> -- we'll mark some failures as expected instead of fixing them,
> and we won't see failures on some configuration. However, I believe
> having a release sooner is more important at this point.
> Thomas, I would like you to express your opinion on this plan.
> Opinions from other Boosters are also appreciated!
I support this aggresive deadline-based approach and very much
appreciate your efforts to get Boost 1.34 out of the door, we've just
been procrastinating way too long. Hopefully, the planned post-1.34
switch to SVN and Beman's always-ready approach to code base
management will avoid these problems in the future.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk