Re: [boost] question/guidence regarding merge to master

Subject: Re: [boost] question/guidence regarding merge to master
From: Robert Ramey (ramey_at_[hidden])
Date: 2019-01-11 21:16:10

On 1/11/19 11:12 AM, Peter Dimov via Boost wrote:
> Robert Ramey wrote:
>> On 1/11/19 10:25 AM, Peter Dimov via Boost wrote:
>> > Andrey Semashev wrote:
>> >
>> >> One thing is true, though. Develop allows other libraries to be 
>> tested >> with your change.
>> >
>> > Precisely.
>>
>> It also allows provisional changes in other libraries to affect one's 
>> own test results.  This can lead to huge wastes of time trying to find 
>> the source of bugs that were "secretly" inserted into your library.
> 
> If you don't do integration testing on develop, you'll do it on master, 
> at a higher cost, when the "provisional" changes land there.
> 
> Or, as they say, if you don't have a test server, you do have a test 
> server, you just call it "production".

It's not that I'm against doing the "integration testing" at all.  I 
recognize that this needs to be done from time to time - presumably soon 
before a new release is shipped.  But if the "next" version of each 
library is tested against the master, integration testing errors should 
almost never occur. But of course theory depends on assumptions that are 
not strictly true (e.g. stable interfaces) so "integration testing" is 
still required.

The problem is that when it is done continuously, transitory errors can 
be tripped in dependent libraries.  Since the dependent libraries 
presume that the other libraries being used are correct, they don't 
really check for errors - they just fail to perform correctly and 
soldier on.  The requires that the working library be investigated to 
discover the source of a flaw which originates outside the library one 
is working on and testing.  It can take a huge amount of time to track 
this down.  Worse, the offending library isn't notified of the problem 
the author is created and time is lost.

Robert Ramey