Re: [boost] El Capitan issues (Was: [1.61] Two weeks remaining for new libraries and breaking changes)

Subject: Re: [boost] El Capitan issues (Was: [1.61] Two weeks remaining for new libraries and breaking changes)
From: Robert Ramey (ramey_at_[hidden])
Date: 2016-02-17 03:25:46

On 2/16/16 11:30 PM, Andrey Semashev wrote:
> On 2016-02-16 22:45, Robert Ramey wrote:
>> On 2/16/16 11:08 AM, Edward Diener wrote:
>>
>>>> Sorry, the suggestion is that on the develop test matrix, each library
>>>> be tested on the develop branch against the other libraries on the
>>>> master branch.  This would permit a developer to make an innocent
>>>> mistake without bringing down the whole system.
>>>
>>> This creates a problem when code in one library in the 'develop' branch
>>> depends on code in another library in the 'develop' branch.
>>
>> I think this is an exceedingly rare occurrence and I doubt that it ever
>> happens.
>
> Just recently I've had another case of synchronized update of multiple
> repositories on develop.
>
> https://github.com/boostorg/winapi/pull/20
> https://github.com/boostorg/dll/pull/7
> https://github.com/boostorg/dll/pull/8
>
> Such situations appear more often than you think.

another case?  Looking at this particular case I think "exceedingly 
rare" is still an accurate characterization.

>
> In general, I want my develop code to be tested against develop of other
> libraries to be able to detect failures before they get released.

When something in your library fails, how do you know whether it's in 
your library or some other library you depend upon?  It can take a huge 
amount of time to find an error in another library.

> I  wouldn't mind to have _additional_ testing against master of all other
> libraries.

This is currently easy to do on your own system.  Just leave the modular 
boost superproject on it's master branch, checkout your particular 
library and switch it to the develop branch.  Now when you run your 
tests locally, you'll be running against the (almost) known good master. 
  So you can be (almost) certain that any problem is in your own code.

In fact, I'm guessing that a lot of people are actually doing this right 
now without realizing it.  The problem comes when they check in the 
develop branch and all of a sudden they're working with other peoples 
(possibly buggy) develop branch and things go haywire.

Think of testing as a scientific experiment to prove/disprove
that your latest changes are correct/incorrect.  The experiment can vary 
only one variable at a time (your code).  If you hold the other 
variables (other's libraries) constant , then your experimental results 
are very hard to interpret.

This is bad enough.  What's worse is that if I check an code containing 
an error into the develop branch, I generate a bunch of failures for 
other library authors.  It makes me reluctant to add/change features.

Robert Ramey