Subject: Re: [boost] [test] trunk breakage
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-01-05 15:32:48
I realise that I've brought this up before, but it seems that there is
an opportunity to get another hearing on it.
I would like to see trunk testing altered so that for each library
it is tested against the release branch of all the other libraries
rather than the trunk versions of all the other libraries as happens now.
Boost.Test is a perfect example. The author of boost test tests his
stuff and checks it into the trunk. This is what he has to do in order
to see his stuff tested on all the other platforms he doesn't have.
>From time to time this is going to reveal a bug that he didn't know
about. So far so good. Except, since all the other libraries are
using this component, they show up with bugs also. Now the
author of Boost Test is on the hot seat and can't work on his
own schedule. The whole boost release is now waiting on him.
It's unfair to the author and breaks/suspends trunk testing
for all the other libraries which might depend upon Boost Test.
Of course this can occur not only with boost test but any
library which is depended upon by others.
Also, the fact that a library passes test against the trunk is
no guarentee that it will pass when merged into the release.
A library might be dependent upon a change which has yet
to be merged into release branch.
This situation wouldn't occur if each library in the trunk was
tested against release.
Vladimir Prus wrote:
> Vladimir Prus wrote:
>>> Gennadiy, I realize this might be a Christmas/New Year break, but
>>> at the same time
>>> we have a "major code changes" deadline on Jan 4th, and such
>>> interruption of test reporting make things hard. Is there any
>>> chance you could investigate? If this issue cannot be sorted out
>>> quickly, we might have to revert the commit for now.
>> This appears to be fixed now. Thanks!
> Unfortunately, not everywhere. MSVC 10 appears to be unhappy:
> What can be done here?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk