From: Beman Dawes (bdawes_at_[hidden])
Date: 2007-10-20 23:19:25
Joel de Guzman wrote:
> Beman Dawes wrote:
>> John Maddock wrote:
>>> Beman Dawes wrote:
>>>> The changes seem to have broken a lot of other libraries tests.
>>>> on VC++ 8.0, for example, went from 16 to 150+.
>>>> Math and Xpressive where hit hard. This may be tough on John and Eric
>>>> because both are actively working on their libraries.
>>>> Please do whatever is necessary to resolve these problems quickly.
>>>> Otherwise it would be a lot better to develop on a branch.
>>> Right, and TR1 fails with:
>>> ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include
>>> 'boost/fusion/sequence/adapted/std_pair.hpp': No such file or directory
>>> Which in turn causes most of Boost.Math to fail :-(
>>> So... what do we do to fix this? Obviously I could point to the new header
>>> (if you tell me where it is!) but then if we merged to the release branch
>>> without *first* merging fusion then it would break all over again - but on
>>> the release branch this time.
>>> Double :-(
>> Joel, this sounds bad. If you don't have an immediate fix, please revert
>> you changes.
> I intend to fix all the affected libraries, but I reverted anyway.
> Sorry for messing the build :(
> Tell me how to proceed. Is the window for change already closed? If so,
> I'm sorry I wasn't aware of it.
The window isn't closed for run-of-the-mill code fixes, but it is closed
for changes that break other libraries. Breaking changes should be made
on a branch. The other affected libraries should also be changed on that
branch, and then when local testing looks good the set can be committed
to trunk as a single change. That way the trunk remains stable.
> There are no changes to the code, just superficial header moves.
From the standpoint of release management, something that causes a
platform's error count to jump from 16 to 154 doesn't look "superficial".
The point isn't to shutdown major changes to libraries, but rather to
use the cheap copies (aka branching) of subversion to keep the trunk
stable yet allow change to happen, albeit on a branch.
It is to be expected that some changes will be made to the trunk that
unexpectedly break other libraries. Part of the rationale for running
the smoke tests is to be able to quickly fix (or revert, if appropriate)
There have been a couple of such cases in the past week where changes
broke far more than expected. But I tried not to growl too much at those
developers because they quickly fixed whatever the problem was.
And there have been a couple of cases where changes broke far more than
expected, and the developers didn't seem to be reacting quickly to the
breakage. Those are the cases where reverting seemed appropriate, so
overall progress could continue while the specific issues got
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk