Re: [boost] All tools code frozen!

From: Vladimir Prus (vladimir_at_[hidden])
Date: 2008-07-22 05:51:16

[I though I've replied to this, but I don't see the reply -- which I definitely
wrote -- neither in sent nor drafts folder. Apologies if somebody gets reply
twice]

Rene Rivera wrote:

> Vladimir Prus wrote:
>> Rene Rivera wrote:
>> 
>>> Since I don't enjoy reverting changes when I don't have the time (I'm in
>>> the middle of my own product release). And since Boost is nearing the
>>> end of a release cycle. *ALL* tool changes are hereby *FROZEN* except
>>> for emergency fixes. Any changes must be approved by Beman or myself.
>>> And such changes must include making sure Boost testing runs adequately
>>> in *both* a Windows platform and a Unix platform. This means going to
>>> the boost-root/status directory and running the tests for *at least one*
>>> library, but preferably all of them.
>>>
>>> Thank you for paying attention.
>> 
>> Pardon me, but what the hell? Do I really need to explain that branches in
>> version control systems are intended specifically so that you don't have
>> to *SHOUT IN EMPHASIZED UPPERCASE* whenever development branch, also known as
>> trunk, gets broke? Or do we to understand that 1.36.0 beta 1, which is due
>> due days ago, is going to be rolled from trunk? Or for some unknown reason,
>> the testing process for release branch uses tools from random other branch?
> 
> 1. Trunk is not the "development" branch. 

Well, the wiki is very clear on that:

  Trunk
  The main development and test location. 

So, as documented, it *is* development branch.

> We've said in the past, as 
> part of the new release procedures, that it should be maintained in a
> stable form. And that "development" should be done in branches as needed
> by individuals. This hold for tools just as much as it holds for libraries.

I don't think I know of any project that believes that it's OK for trunk
to be broken (as in, regression tests failing) for a significant periods of
time. But on the other hand, I don't think I know any project where issues
appearing in trunk result in immediate revert of the commit. I don't think
the Boost wiki documents such drastic approach either, and I don't think it
should.

The commit in question is an isolated commit, which is not part of any
major rework supposed to caused any instability. "Developing" it on branch
would be fairly weird, and given that we don't have any way to run tests
on random branch, it might not prevent any mistakes.

> 2. Testing uses the BBv2 tools from trunk because it's been pointed out
> before, not sure if it was you, that the trunk BBv2 tools should be the
> ones released with the Boost releases. Hence we need to test with those
> tools. I'm more than happy to have a BBv2 release that we could use for
> testing that is sufficiently stable and has all the needed fixes for a
> Boost release.

I don't think I said exactly that. I do think that on the average, any
random snapshot of Boost.Build is strictly better than either the previous
release, or the state included in previous C++ Boost release, and so trunk
state at some point should be automatically included in next C++ Boost
release. But I never said you should use "live" trunk version for C++ Boost
releases, precisely for the same reason you don't use "live" trunk version
of any individual library.

As soon as merge from trunk to release branch is made, the release branch
version of Boost.Build should be used for testing the release, and only
fixes for issues found during such testing should be further merged. There's
no need to make formal release of Boost.Build, just as you don't require
separate formal release of each Boost library to be included in upcoming
C++ Boost release.

So, what prevents using release version of Boost.Build, and other tools,
for testing the release? Can you adjust the testing infrastructure to
do so?

- Volodya