Re: [boost] [Fusion] Onward towards 2.1

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.
>>>> Failures
>>>> 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:
>>>
>>> compile-c-c++ 
>>> ..\..\..\bin.v2\libs\tr1\test\test_tr1_include.test\msvc-8.0\debug
>>> \threading-multi\test_tr1_include.obj
>>> test_tr1_include.cpp
>>> ..\..\..\boost/tr1/tuple.hpp(51) : fatal error C1083: Cannot open include 
>>> file:
>>> '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 :-(
>>>
>>> Ideas?
>> 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) 
such breakages.

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 
straightened out.

--Beman

--Beman