Re: [boost] Boost Development Environment proposal

From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-03 12:41:00

Halleluhuh!!!

Here are my observations: Mostly minor quibbles

"Objectives"

"A developer may at any time request non-invasive tests of a library's 
development branch on any or all platforms against any stable branch of the 
other libraries. The non-invasive requirement ensures that problems in the 
development branch of the library being tested do not destabilize the stable 
branch being tested against. The on-demand requirement ensures that 
developers receive timely test results. Running tests against stable 
branches of other libraries ensures the tests are run in a stable 
environment."

This section doesn't seem to belong to "Objectives" as it pre-suppose the 
solution described subsquently in "Policies".  I think it should be move 
down to that section.

"Policies"

"Integration of a development branch into a stable branch only occurs after 
the integration is proven to be stable."

When I first read the document it wasn't clear to me whether it referred to 
one
development branch or one development branch for each library. I
presume we mean the latter. (plus one each for bjam, quickbooks and ?, see 
below).

"Reduction in tool fragility is a general goal, because tool fragility"

Tools for build and testing should be part of the same system.  Currently
Boost Test is part of this system so that would be fine.  Bjam.v2 should
also be sjubect to the same procedure.  Of course this would mean that
tools like bjam and quickbooks should have their own test suites which
can be run on a separate branch until they are determined to be
"release stable".  In other words, tools for building boost should
be subject to the same standards and procedures that boost libraries
are.

"Scenarios"

"A library has been modified and tested locally on a development branch, and 
needs to be tested on other platforms. These tests must be against one or 
more of the stable branches. Variation: the library is a dependency of other 
libraries, so they must also be tested to ensure they have not been broken 
by changes to the base library."

I don't think this second sentence is correct.  If a library is tested 
against the
stable branch and errors are found, they are either in the library tested
or in another library already in the stable branch.  If its the former, the
test fails and the library cannot be merged into the stable branch.  If its
the latter, the stable branch has a bug and it should be handled according
to the procedure for that case.  The developer of the dependent library
has the choice to either workaround the problem or wait for the bug
in the stable branch to be fixed.

"A request for the latest snapshot of one of the stable branches."

I don't understand what this means.

"[A] Bug is found in one of the stable branches. The fix must be done in 
such a way that there is no possibility of the stable branch becoming 
unstable.

This should be handled as any other case.  The bug is already there and had 
been
released.  Its probably been there for a while so its not cropping up 
everywhere.
That is its not any more urgent than any other enhancement or bug.  So I 
would say
that the correct procedure for addressing a bug in the stable branch is:

a) open up the developement branch.
b) make up a test which traps the bug and add the test to the library's test 
suite.
c) Continue as with any other library enhancement.

Thus, though we can't guarantee perfection, this will guarentee continuous 
improvement.

"A new release of a ccompiler breaks existing libraries."
"A new release of a non-critical compiler breaks existing libraries."
"A library wishes to support a compiler that is not on the 
"release-critical"

I think the whole concept of classification of compilers is sort of red 
herring
and adds work and complication in an attempt to address an unaddressable
situation.  Suppose we have two libaries

a) boost.lambda - it unrealistic and unproductive to use this library with
an older compiler.  This is not a problem as no reasonable person is going
to expect or attempt to do this.

b) boost serialization - this library supports borand compilers back to 
5.51.
And some users find this useful. And it doesn't cost anything to leave it 
in.

So don't see where a boost wide concept of "release critical" compiler
can be defined.  Boost already has the policy that code should compile
on a standards conforming compiler and that it shouldn't be rejected
if a some inconformant compiler (basically all f them) can't compile
something in the library.

So I would suggest that each "stable" version has matrix which for
every combination of library/compiler shows support or non-support.
Actually we already have this in the test matrix.

So when a new release of compiler x comes out, there is nothing urgent
to do - nothing is "broken" its just that that compiler support boost
only up to "version xxx" ( more on that later) until library developers
get around to catching up.

"A library is to be separately released. This separate release is to include 
both the library and its dependencies"

The desire or percieved necessity that a library needs to be separately 
releasable
should be seen that the library developer has found the system lacking. That 
is,
if the procedures realize the stated objectives, there should be no 
incentive to
making a separate release.

I envision that one might spend some time on the development branch and
testing at home until things are as perfect as I can make them.  Then I 
request
a test to check against the compilers I don't have.  A couple of iterations 
on that
and now I as to be merged into the stable branch.  Things
should pass.  (Since we've already tested my changes, we're just re-running 
the
tests on all the other libraries so the only surprises should come in 
libraries
which depend on mine if and only if I broke an interface).  At this point
the "stable" branch is a "guarenteed improvement" so there is no point
in NOT releasing it"

So I would expect a new "release" every month or so.

So why would a developer go through the hassle of a separate release just
get changes to users and average of two weeks sooner?

Misceleanous

The term "stable" bugs me.  It suggests "good enough", "not getting worse"
in general it pessimistic.  I would prefer "release" or "release candidate" 
which
I think is more accurate anyway.

Robert Ramey

Beman Dawes wrote:
> There is a fresh draft of a Boost Development Environment proposal up
> at http://mysite.verizon.net/beman/development_environment.html