From: David Abrahams (dave_at_[hidden])
Date: 2007-10-17 11:01:55
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-boost-bin-v2-libs-python-test-exec-test-msvc-8-0-debug-threading-multi_release.html
>>
>> * 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