Boost logo

Boost :

Subject: Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2015-10-05 03:54:32

Le 04/10/15 15:37, Edward Diener a écrit :
> On 10/04/2015 08:49 AM, Raffi Enficiaud wrote:
>> Le 04/10/15 13:38, John Maddock a écrit :
>>> On 04/10/2015 12:09, Bjorn Reese wrote:
>>> As many others have said, Boost.Test is "special" in that the majority
>>> of Boost's tests depend on it. Even breakages in develop are extremely
>>> painful in that they effectively halt progress for any Boost library
>>> which uses Test for testing.
>> Also special in the sense that boost.test cannot take full benefit from
>> the current test dashboard setup: we have to test all libraries before
>> being able to push to develop
> Ideally yes, but in practicality you should be able to determine whether
> or not a change to Boost Test is working properly by only testing a very
> few libraries which you know use Boost Test's facilities extensively.
> Furthermore this situation will make absolutely no difference whether
> you use C++03 or C++11.
>> , which means hours and hours of testing
>> and infrastructure deployment/maintenance for a single push to a branch
>> that is supposed to help us develop boost.test. To be frank, I do not
>> think that this requirement on boost.test makes sense.
> First you claim a completely unreasonable practical requirement and then
> you say it makes no sense.

I thought it was your claim, but apparently you're saying that our test
setup is not good enough, and the compilation of a subset of boost with
our changes to develop should be part of the pre-push tests.

How easy it is to add tests from other libraries directly in boost.test
tests? I am far from being a Bjam expert.

>>> As for testing in C++03 mode - that's easy, just use GCC's default
>>> compiler mode ;-)
>> I have also a similar setup on OSX, but this does not prevent us from
>> making mistakes, and capturing those mistakes before it goes to master
>> is the very purpose of the develop branch.
> What does what John suggested have to do with the 'develop' branch
> versus the 'master' branch ?

The problems that are arising in the ML are /only/ about the develop
branch, mainly because sometimes we do not have the proper setup to
catch some of the problems (MSVC8 for instance). According to the whole
discussion thread here, boost.test is not supposed to make mistakes in
the develop branch. OTOH, develop goes to master if and only if tests
are ok, and only master is eligible for a release.

I do not see there anything not related to develop vs master, or the
development workflow in general. Since according to you, I am missing
something, please tell me why "develop vs. master" is off-topic.


Boost list run by bdawes at, gregod at, cpdaniel at, john at