Re: [boost] [1.35.0] Developer preparation

From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-10-17 06:57:52

David Abrahams wrote:
> on Thu Oct 04 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
> 
>> Until further notice, the plan is to do quarterly Boost releases, and 
>> stick to that schedule even if updates for particular libraries aren't 
>> ready.
>>
>> If a library on the trunk isn't ready for a release, the prior release 
>> will be used for that library.
>>
>> I hoping for a final cut-off date of Friday, October 19, for making 
>> "go/no-go" decisions on which library updates make it into 1.35.0. 
> 
> Well, I'm just going through re-entry from Kona, so that gives me very
> little time to do anything.
> 
>> That means libraries with updates to be included should be passing
>> regression tests on trunk well before then. The process of merging
>> into the release branch will start sooner for libraries already
>> ready.
>>
>> Here is what developers should be doing over the next two weeks:
>>
>>      * 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?

> * 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).

> 
> 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.

>  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.

>  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.

--Beman