Re: [boost] [1.35.0] Developer preparation

From: David Abrahams (dave_at_[hidden])
Date: 2007-10-16 07:34:40

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.

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

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.

>      * 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.  Do you want me to
replace the trunk with 1.34.1?  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.  What

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com