on Wed Oct 17 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
* Start watching the regression tests at http://beta.boost.org/development/tests/trunk/developer/summary.html
OK. My errors look like they are exclusively either:
* Linker errors due to a mis-specified set of system libraries that needs to link with various Python components. That should be a relatively easy Boost.Build fix.
Is someone working on this fix?
Not yet; I've barely had time to assess the situation. I may be able to work on that today.
* Tester misconfiguration issues, as in http://beta.boost.org/development/tests/trunk/developer/output/RSI%20Kludge-...
* The import_ test failure. That's Stefan Seefeld's baby and I've asked him to look into it.
Please keep pestering him or markup the test as an expected failure (unless you consider it a showstopper).
So far he hasn't responded, which worries me a little. I object to marking it up as an expected failure; I don't expect it to fail, and I would rather take the feature out if we can't support it.
Also, I had stopped maintaining trunk a long time ago, when I incorrectly understood that we were going to restart from 1.34.x for the next release, so I'm not 100% confident that my work on 1.34 has all been merged to the trunk for any of my libs. Not moving tests over could hide a feature removal, so I need to look at that for all my libs, not just Python.
Understood.
* For release criteria compilers, fix or markup all failures caused by your library's code. Fix or markup failures caused by your library's code for other compilers according to your own judgment.
* For release criteria compilers show failures you think are caused by some other library's code, or by test configuration problems, post list notifications directed at the library or tool causing the problem. For other compilers, do the same if you wish.
* For testing on the trunk to be a reliable indicator of release stability, prerequisite libraries on the trunk must be ready for release. If the trunk for your library isn't going to be ready in time for this release, please make a branch of the trunk with your library's name, and "merge" the trunk for your library so it is identical to 1.34.1.
Well, I'll certainly need a few more days than "until friday" if Boost.Python is going to be ready for this release.
That Friday date will have to be deferred, although I'm still planning to issue a progress report on Friday. With the tarball testers still broken, we just aren't making the progress hoped for.
Good, well there's a chance, then.
Do you want me to replace the trunk with 1.34.1?
That's up to you. You can also simply ask that Boost.Python trunk not be merged into the release, thus skipping all Boost.Python updates for 1.35.0.
You may not be worried about it, but I am not willing for my own libraries to differ substantially in the long term between the trunk and the release branch. If I have to tell you not to do the merge, I'm also going to roll the broken parts out of the trunk.
We seem to be testing some compilers for 1.35 that we weren't testing for 1.34.1, so I don't have any confidence that it will actually fix the failures we're seeing.
Testing continues to be a serious problem. Intellectually I knew that because of Thomas Witt's experiences, but now that I'm the one having to cope with it, our testing unreliability has really hit home.
Heh, enjoy ;-) -- Dave Abrahams Boost Consulting http://www.boost-consulting.com