Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)

Subject: Re: [boost] boost.test regression or behavior change (was Re: Boost.lockfree)
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-10-05 09:07:56

On 10/05/2015 03:54 AM, Raffi Enficiaud wrote:
> 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.

I am saying that your claim that Boost Test has to test all libraries 
before you push to 'develop' is an unreasonable practical requirement, 
and then you follow up by saying 'I do not think that this requirement 
on boost.test makes sense'. You yourself establish the requirement and 
then you complain of it as taking up too much time.

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

Nobody is arguing that making mistakes in the 'develop' branch does not 
occur. Gennady's response, however, was not that this was a mistake but 
a chosen decision to drop support for testing in anything other than 
C++11 mode. In other words he was saying that the change in 'develop' 
was not done by accident but done knowingly on purpose.

Everybody is asking Boost Test to desist in the 'develop' branch from 
requiring libraries which use Boost Test to be compiled with C++11 
support. Doing so can easily break the 'develop' test matrix for 
libraries which compile their tests in C++03 mode.

John Maddock's comment about using gcc in it's default compiler mode of 
C++03 support was in response to your complaint that testing Boost Test 
using C++03 was a resource burden for Boost Test.

But let's just move on. No one is seeking to lay blame on anyone for 
anything. Lots of libraries use Boost Test which need to be tested in 
C++03 mode so if Boost Test wants to move forward with a version which 
only supports testing in C++11 mode in order to use C++11 facilities, 
which is perfectly reasonable, it should do so as a separate library 
forked from the current version of Boost Test.

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