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. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo