Boost logo

Boost :

From: Emil Dotchevski (emil_at_[hidden])
Date: 2008-07-18 19:41:59


On Fri, Jul 18, 2008 at 4:18 PM, David Abrahams <dave_at_[hidden]> wrote:
>
> on Fri Jul 18 2008, Rene Rivera <grafikrobot-AT-gmail.com> 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. 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've said that over and over, but I don't remember ever reaching
> consensus on it. Regardless, I don't think we can expect such an
> important policy to stick unless we can point at a web page that says
> so. Care to build one?

You know the saying, speed doesn't kill -- the sudden stop does?

If the motivation for branching is to prevent interim commits of work
in progress, then I suggest stating *that* as requirement.

OTOH, anything that hasn't been tested should be considered work in
progress, and to test a change it has to be committed to Trunk -- not
only because Trunk is the thing that gets tested, but also because
many changes can produce ripple effects throughout Boost. Add to that
the testing lag, and it's a given: Trunk is potentially not very
stable.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk