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

Subject: Re: [boost] [Git] Documentation for Git and Modular Boost conversion
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-12-17 17:53:38

Peter Dimov wrote:
> Dave Abrahams wrote:
>> 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).
>
> This is fine in some scenarios, not so fine in others. Imagine that
> the "develop" branch of, say, SmartPtr introduces a potentially
> breaking change, say, use of explicit operator bool. Until dependent
> libraries are tested against this change, it will not become known
> whether they are affected.

This is effectively the same as using all the other libraries to test
the one library with the change.  There are a number of reasons
I don't like this idea.

a) It consumes a large number of resources - a change on in
one library triggers tests on all other libraries which might
depend upon it.

b) When a change in library A provokes a failure in library B
library B's author has to go on a bug hunt to eventually
conclude that the error was caused in some place where
he had no place to look.

c) library B's tests are really designed to check pre-requisite
library A.  They just assume that library A works. If they
can't assume that - then the tests for library B have to be
a lot more complicated.  Then it's even harder to find
the source of a failure.

d) The real solution is to add more tests to library A.  But
that's hard now since our testing infrastructure is heavily
loaded - in large part re-testing depending libraries.

e) some libraries like boost test are used in the testing
itself.  These can't be "under construction" at the same time
they are being used as part of the test infrastructure.

I would like to re-iterate the idea that trunk and release
libraries be tested against the next release (ie the current
release branch).

Robert Ramey

PS - On personal machine, I have the release branch loaded
and just switched to the trunk for the serialization library.
This has made my life much easier since I've avoid the above
problems.

PPS - Hmmm - I wonder if this will be possible/easy under
the Git system.

>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost