Re: [Boost-build] [Boost-cvs] CVS: boost/tools/build/v2/tools gcc.jam, 1.82, 1.83

From: Eric Niebler (eric_at_[hidden])
Date: 2006-10-26 13:51:48

Vladimir Prus wrote:
> On Thursday 26 October 2006 01:06, Eric Niebler wrote:
>> Rene Rivera wrote:
>>> Eric Niebler wrote:
>>
>> I'm also not wild for the idea having a specially tagged "known good"
>> BBv2. What's on HEAD should be "known good," and HEAD should be what the
>> nightly regression tests are testing. A more comprehensive BBv2
>> regression test is all that should be needed, IMO. A few people were
>> broken by these changes. Their configurations should be captured in test
>> cases so the bugs don't creep back in.
> 
> The problem is not the regression tests. In fact, my nightly build -- which is 
> automated -- crashed right after this change went in, so post-checkin testing 
> caught this problem just fine.

Phwew! That's comforting.

> The problem is that Rene does not have access to Ubuntu's gcc compiler, nor to 
> cygwin's gcc compiler, so he could not test with those compilers.

That's a problem. No *nix? No Windows? Rene, what do you use, a Mac? If 
you're going to be hacking toolsets, we need to get you access to 
platforms you can test on.

/me wishes once again for a Boost compile farm.

>> If the BBv2 regression test cannot be made comprehensive enough, I'd
>> rather see an experimental branch for toolset changes that some on this
>> list (myself included) sync to. That branch gets merged into HEAD
>> periodically if none of us guinea pigs have complained.
>>
>> But that's a poor substitute for a good set of BBv2 regression tests.
> 
> We've being though this before on Boost mailing list. IIRC, that was in 
> relation either to Boost.Serialization or Boost.Test -- where each change 
> either requires a lot of time in recompilation or potentially breaks a lot of 
> code. The idea was to have a separate branch, where changes should be 
> preliminary tested before disruption HEAD.
> 
> In that case, just like in the present case, the problem is not in the number 
> or quality of regression tests. The question is how to test a change that can 
> break one of 100 different gcc versions out there without committing it to 
> HEAD. Perhaps the right solution is just to ask on mailing list for more 
> testing for disruptive patches -- they don't appear too often.

Yes, that sounds about right. But an UNSTABLE branch would make this 
scenario easier.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com