Re: [Boost-build] Boost.Build causing failures on the release branch (and Trunk too)

Subject: Re: [Boost-build] Boost.Build causing failures on the release branch (and Trunk too)
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2008-11-19 23:41:56

Sorry, still too busy to give much feedback on this stuff. I literally 
got home a few minutes ago and I already need to back to sleep :-(

Vladimir Prus wrote:
> John Maddock wrote:
> 
>> There seem to be a lot of failures on the release branch caused by some
>> libraries not being found, so for example on acc:
>>
>> http://tinyurl.com/6r76o5
>>
>> or on Darwin:
>>
>> http://tinyurl.com/6dyezn
>>
>> The library not being found is part of the project requirements BTW in case
>> that helps,
> 
> On the *release* branch? I am confused what is going on -- the only explanation
> would be that trunk Boost.Build is being used to test release state of C++ Boost.
> Ah, right, I recall we discussed this being the case. So, to summarize,
> the current testing arrangement appears to be:
> 
> 1. For release branch:
> 
>         - C++ Boost -- release branch
>         - Boost.Jam -- stable release
>         - Boost.Build -- bleeding edge
> 
> 2. For trunk:
> 
>         - C++ Boost -- bleeding edge
>         - Boost.Jam -- stable release
>         - Boost.Build -- bleeding edge

Yep. And when I brought up the release testing last year, I mentioned 
that the ideal for C++ Boost would be:

   - C++ Boost -- release branch or bleeding edge
   - Boost.Jam -- stable release
   - Boost.Build -- stable release

But there wasn't a stable Boost.Build at the time, and it didn't look 
like there would be one for some time. Especially as it would mean 
changing the BB release process a little bit to have formal releases. 
The rationale is that C++ Boost is a *user* of bjam and BB, and hence 
should only ever be using/testing with release tools. And that the tools 
should be tested separately, and exhaustively. Hence I want a tools 
testing process so that we can hammer on the tools repeatedly and 
quickly without worrying about the possibility of breaking C++ Boost 
testing. I know it seems strange for me to say this, but the BB failures 
are an example of the kind of failures we used to see many times for C++ 
Boost testing which was a horrible pain as it would stall C++ Boost 
testing. And that is the key problem we must avoid. The current 
compromise is not ideal, but it's just slightly less problematic than it 
used to be.

> Seem fairly strange to me.

It's only strange because it's a compromise.

> For one thing, as I've complained already on
> boost-testing, we never test Boost.Jam trunk + Boost.Build trunk, so
> we'll never detect any breakage in that combination. And at the same
> time, we use in-development version of Boost.Build for release testing.
> 
> I would say we should use release branch version of everything for
> release branch, and trunk version of everything for trunk.

The testing I want to see is:

   - All C++ Boost use release quality tools.
   - All tools tested to the same level as C++ Boost. Which would also 
include testing C++ Boost, release and trunk, with development level tools.

But this, of course, means more testing resources.

PS. And yes, I'll finally be getting around to putting together the next 
bjam release this weekend assuming I don't end up working overtime. As I 
finally have my Linux machine/partition running again.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org (msn) - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail