Re: [boost] [1.36.0] Libraries with unmerged changes?

From: David Abrahams (dave_at_[hidden])
Date: 2008-07-16 10:06:44

on Wed Jul 16 2008, "Emil Dotchevski" <emil-AT-revergestudios.com> wrote:

> On Tue, Jul 15, 2008 at 10:29 PM, David Abrahams <dave_at_[hidden]> wrote:
>> I was talking about relying on dependent libraries catching bugs in a
>> dependency (e.g. serialization's tests uncovering breakage in type
>> traits).  Sounds like you're talking about the other direction, sort of.
>
> I agree that we don't want to rely on dependent libs to catch bugs in
> a dependency, but sometimes this does happen. 

Yes.

> When a serialization
> library test fails, we can't without further investigation assume that
> some other library is to blame, even if the serialization library
> tests pass with the last and the next release of Boost.

Now you seem to be making the opposite point; that it might be a
Boost.Serialization bug.

>>> For example, you might depend on an implementation detail of another
>>> library without knowing it (note that "not knowing it" isn't always a
>>> matter of being careless.)
>>
>> It isn't?
>
> Not always. For example, the dependency may be indirect, through
> another library. Or, it might be due to buggy or incomplete
> documentation.

Somebody was careless in that case.

>>> This might become source of regressions, which are typically
>>> undetected until the implementation of the dependent library changes.
>>
>> Sure.  What's your point?
>
> That it is a bad idea to avoid testing an (even stable) library
> against the (unstable) trunk just because this may produce bogus
> failures.

OK, I guess

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com