Re: [boost] [Git] Documentation for Git and Modular Boost conversion

Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-17 14:22:11

on Mon Dec 17 2012, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:

> Dave Abrahams wrote:
>
>> on Sun Dec 16 2012, "Peter Dimov" wrote:
>> 
>>> I wonder how testing will work. Will the "develop" and "master"
>>> branches of each repo be tested? 
>> 
>> What's going to be tested is fluid.  The ultimate goal is to allow
>> developers to request specific combinations of tests with each commit by
>> modifying a .json file in their project's root directory.  In the
>> meantime, I expect to test every commit on any branch.
>
> Wouldn't the latter be a giant amount of work for the testers?

No, it will happen automatically.  Testers aren't going to have to
intercede.

> I do subscribe to the idea that testing should be configurable by the 
> developers. I'm not sure whether a file that is subject to version 
> control would be a wise way to provide for that configurability.

We've thought it through for years and IMO it's an extremely attractive
option.  Having a record of exactly what was tested alongside the commit
seems like a good idea to me.  What is your objection?

> Not all testing should be optional, I think; 

Of course not.

> form my understanding of the purpose of the test infrastructure it
> seems that the temporary release branches (gitflow style) should
> always be tested.

Sure.

>> The biggest question is against which versions of Boost dependencies the
>> commit will be tested.  The obvious choices are 1. the version that was
>> part of the last boost release, and 2. the last version of the
>> dependency to be individually released (i.e. that dependency's "master"
>> branch).
>> 
>> Feedback/opinions on that choice are most welcome.
>
> Definitely option 2, conflicts are likely to be found sooner in that 
> way.

The downside of that approach is that one library developer creating a
broken individual release may break testing for all other libraries,
causing general instability and upset.  That is currently the case for
many people with trunk testing today, and some of us have been arguing
for a long while that it would be better to do most testing against the
last stable release of a library.  Presumably that effect would be
somewhat mitigated by testing against only *releases* of individual
library dependencies, but it would not be entirely eliminated.

We can avoid this problem by allowing developers to decide which version
of individual dependencies they want to test against.  In general one
might want to stick with the last released Boost version, but
occasionally one might need features developed during the current Boost
release cycle, in which case the .json file could specify a later
revision.

-- 
Dave Abrahams
BoostPro Computing                  Software Development        Training
http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost