Beman Dawes wrote:
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.
Done.
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".
Understood. I should have been more careful.
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.
Ok.
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.
I'm hoping my revert a few hours ago was quick enough. I understand the frustration and I can assure you that I won't commit the same mistake again. At any rate, I've done everything on a branch and tests are looking good on all libraries that use Fusion (testing done locally). Now, I need to know what to do next. I'd really rather have this in but I can understand if it's no longer possible at this point. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net