Re: [boost] [1.38] CMake support added to release branch?

Subject: Re: [boost] [1.38] CMake support added to release branch?
From: Robert Ramey (ramey_at_[hidden])
Date: 2009-02-01 17:48:19

Beman Dawes wrote:
> On Sat, Jan 31, 2009 at 11:57 AM, John Maddock
> <john_at_[hidden]> wrote:
>> I see from the 1.38 news section that experimental CMake support has
>> been added to the release: I thought we were going to have a review
>> before this happened?
>
> Hum... I must have missed that discussion, and OK'ed the request to
> merge.
>
> The CMake support is certainly experimental, but do you think there is
> any harm done by including it in the release in its current state?  We
> can certainly publicize the fact that the support is experimental.

Currently, there are some things in the release which are not explicitly 
tested.
Basically, these are test tools such as bjam of boost build, boost book, and
perhaps others.  Including CMake in the release would be consistent with
current and recent practice.

However, I believe the boost libraries could benefit by requiring that the
same standards applied to libraries be applied to all tools delivered with
the library.  I see no justification for tools meeting a lessor standard 
than
libraries.

In one sense this isn't a huge deal as - at least in the case of
build tools - they pretty well tested as a side effect of being used to test
other libraries.  But I think boost would benefit by setting the same
high standard for libraries and tools.  This standard would state:

a) all released libraries and tools have been reviewed.
b) all released libraries and tools are explicitly unit tested.
c) all released libraries and tools meet some minimal standard
for documentation and examples.

So any user of the release would know that

a) is it is meant to be used out of the box for production code.
b) given the uniformly high standard to which all components are subjected,
any failure, error, confusion regarding the documentation etc. is likely
an error or oversight on the part of user and merits a more careful
examination before raising the issue on the list.
c) after consideration of b) above, any failure, error, confusion regarding
the documentation etc. is unknown to boost developers and merits an
error report.

This will make it much more efficient to use boost.

The alternative of
having a policy of including expermental/untested/unreviewed code in the
release is that every time the user has some sort of problem, he has to
consider that the problem is not caused by him.  Simple economics
mean that he'll do the easiest first - query the list or assume its a known
problem.  Basically, once code that doesn't meet some standard is
admitted, then every time a problem occurs, one has to consider the
possibility that the code doesn't meet the normal standard and this takes
a lot of time.

To summarize:
a) set standards for all components - tools and libraries in the release
b) insist that all components meet the same standard.
c) tell users a) and b) above and this release is the best we know how
to do at the time of release.

If one want's to create experimental "add-on" packages, that's fine - just
don't package them in the release.  These experimental add-on's can
be on thier own track of development and be "mixed-in" at the user's
discretion - assuming they are compatible with the public API of the
libraries - which is another discussion we needn't go into there.

Robert Ramey

>
> --Beman
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost