Re: [boost] [Git] Regression testing modular Boost

Subject: Re: [boost] [Git] Regression testing modular Boost
From: Dave Abrahams (dave_at_[hidden])
Date: 2012-12-26 11:08:20

on Tue Dec 25 2012, "Robert Ramey" <ramey-AT-rrsd.com> wrote:

> Daniel Pfeifer wrote:
>> 2012/12/25 Rene Rivera <grafikrobot_at_[hidden]>
>>
>>> On 12/17/2012 12:25 PM, Dave Abrahams wrote:
>>>
>>> I don't know what you mean by "real modularity".
>>
>>
>> Monolithic development (currently): There is one repository, one
>> release cycle.
>
>> Modularized development (proposed): Each module has its own
>> repository and release cycle.
>
> This would suggest that each library have it's own versioning sequence.

That is the plan

> This in turn would suggest that each library have a list of dependcies.
> Each entry in this list would be the the pre-requisite library along with
> the minimum version number required.

It's not just about the minimum version number; version compatibility
can be more complicated than that.  Providing for that is also the plan
but it's not part of the immediate Git transition.

>> Optional: Multiple release cycles may be synced. Multiple modules may
>> be delivered as one package.
>
>> Is there room for misunderstanding? Maybe it is unclear what Boost's
>> future development/test/release process will be like. But the meaning
>> of "real modularity" should be clear, no?
>
> lol - maybe - but I think we'll see otherwise.  FWIW I agree with
> your concept of "real modularity" - but that would be a big step for
> us and we're not currently prepared for this.

Of course we don't think Boost is prepared today, but we've been
planning this stuff for quite some time and have specific approaches and
technology in place that will help Boost to become prepared.  If you're
interested in the details of medium-to-long-term plans, those should
probably be discussed on the ryppl-dev mailing list (see Google Groups).

>> But the testers *must* test what Boost delivers as a package. At some
>> point end users get a Boost installed. And that's what we have to test. If
>> we don't test that we will have unknown issues to deal with.
>
> Hmmm - I would say at some point the package to be deployed by the
> boost organization should be tested.  This should mean that each library
> is tested against all the other libraries in the package.
>
> But for developers and "testers" there is no reason to require that
> the be testing the whole of boost. If a particular library is tested against
> the current (or next) release deployment, that should be enough.

You're mixing up the immediate steps with things that can/should happen
down the road.  Immediately the goal is to make the transition to
modularized Git repositories without changing other procedures more than
necessary.  That means maintaining the current testing protocols and
results.  We have plans to improve testing in bigger ways, but that's a
separate step.

>> Absolutely! Boost should continue to provide monolithic packages. And
>> these packages need to be tested.
>> What we want to modularize is the development. Not the package that we
>> provide to end users.
>
> If each library has been tested against the release, there is no reason that
> the deployment need be complete.  Anyone could deploy a subset if
> they wanted. 

Anyone could, but AFAICT Boost has no incentive to do so.

> We even have BCP to help that along.

We won't need BCP much longer.  Once library dependencies are declared,
as part of build system files and/or ryppl feeds, it will be obsolete.

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