Re: [boost] [test] trunk breakage

Subject: Re: [boost] [test] trunk breakage
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2010-01-06 09:14:38

Eric Niebler wrote:
> (Cross-posting to boost-testing and boost-devel...)
> 
> On 1/6/2010 7:32 AM, Robert Ramey wrote:
>> This situation wouldn't occur if each library in the trunk was
>> tested against release.
> 
> I agree that the current situation, where we have several single points 
> of failure -- a bug introduced by one component on trunk gumming up the 
> whole works for everyone -- is unsatisfying. Your suggestion sounds 
> reasonable, but I don't know enough about our test infrastructure to see 
> the possible implications for our test runners and for our developers.
> 
> One concern I have is that most developers will not be running their own 
> tests in this configuration before committing to trunk.

It could be arranged that developers would also need to do their local 
testing in the same library+release configuration.

> I suppose that's 
> not so bad because at worst, their component ends up broken on trunk, 
> but the rest of the world is unaffected because presumably they haven't 
> merged their broken change to release yet (and everybody else is using 
> the last-known-good version of that component from release).
> 
> Can someone who knows more about our test infrastructure say a bit more 
> about Robert's suggestion? As a half-measure, we could treat Boost.Build 
> and Boost.Test as special and have the test runners use the versions on 
> the release branch.

It's not a half measure, it's actually the ideal testing situation and 
the current test scripts are somewhat arranged to handle this because it 
was the ultimate goal of testing when I started rewriting them. And at 
this time Boost.Build and some of the other infrastructure tools already 
use specific release only versions for testing. Specifically only the 
released Boost.Jam is used for testing, and Boost.Build and the release 
tools could be changed to use specific versions.. As long as they are 
tagged in SVN. That was the good news.

The bad news is that there would need to be additional work to make the 
test scripts do the same for libraries. Which would not be a big amount 
of work.

The really bad news, is that in order to make such testing possible at 
the library level would require that the Boost sources are modularized 
into the library parts so that the scripts can manufacture a complete 
Boost from the modules.

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