Re: [boost] [1.35.0] Developer preparation

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