Re: [boost] Process discussions

Subject: Re: [boost] Process discussions
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-02-02 02:49:50

On Tue, Feb 1, 2011 at 8:57 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:
> On 2/1/2011 7:21 PM, Dave Abrahams wrote:
>>
>> At Tue, 01 Feb 2011 10:12:45 -0600,
>> Rene Rivera wrote:
>>>
>>> That is, I don't think we can live without full trunk testing.
>>
>> I'm curious why not.  I'm fairly sure I don't want any resources wasted on
>> it for my libraries.
>
> Because in the three testing scenarios I mentioned it would be the only one
> to give you fully integrated testing without being in the release.

What does "fully integrated testing" mean, though [I mean that in two
senses: 1. what's your definition, and 2. rhetorically, does it have
any meaning]?  You're not testing against any past or future released
state of other libraries.  Someone could have checked in minimal
changes to the release branch and be off exploring some grand rewrite
on trunk for which there's no intention that it be in the next
release.

> Of course
> a full dependency integrated testing of an individual lib with a release
> base could be a substitute for full trunk testing. But for some components
> full dependency integrated testing might devolve back to close to full trunk
> testing. But again, this all depends on how close or far future procedures
> are to the current ones.

Sorry, I guess you lost me.

Here's what I want:

Each change I make is tested against the previous released state of
the rest of Boost (so I'm not trying to manage a moving target),
unless otherwise specified.  I might specify otherwise if my new work
depends on an upcoming-but-not-yet-released version of another
library, for example.

I think Boost release managers would want the latest releasable state
of all libraries tested against one another, unless otherwise
specified.  In today's world that corresponds to testing the release
branch.  Whenever that is "all green," they can spin the release.
They might specify otherwise, for example, if they had to roll back to
an earlier released or releasable state of one of the libraries.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com