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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk