Re: [boost] A proposal for superproject structure and testing

Subject: Re: [boost] A proposal for superproject structure and testing
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-12-10 11:16:03

On Mon, Dec 9, 2013 at 6:42 PM, Peter Dimov <lists_at_[hidden]> wrote:

> Cox, Michael wrote:
>
> ...
>
>
>  I'm assuming the criteria to merge a feature branch to the develop branch
>> is that it builds and the unit-tests all pass with the current HEADs of the
>> develop branches of all the other submodules.
>>
>
> That's very unlikely. One, nobody does a full Boost test cycle before
> integrating work into develop, because a single compiler takes (I think) 8
> hours or so, and you need at least two [platforms], if not more. Two, unit
> tests don't just have to pass on a single compiler, and the test
> infrastructure doesn't take "test my feature branch please" requests at the
> moment. So you have to merge to develop in order to have the change tested
> on the full range of compilers.
>
> In practice, our current workflow has been: you test locally on a few
> compilers, merge (or push) into develop, wait three days to a week for the
> tests to cycle, and if everything looks fine and nobody politely informs
> you that their library suddenly broke, merge into master. Or forget to
> merge into master, as the case might often be with svn.
>

In other words, Boost testing has complexity l*m*n where l is the number of
libraries, m is the number of platforms, and n is the number of compilers
for the platform.

That's the reality behind Peter's suggestions. Git and modular boost can
reduce some of the fallout, but we still have to cope with that underlying
reality.

--Beman