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

Subject: Re: [boost] [1.38] CMake support added to release branch?
From: Max (loadcom_at_[hidden])
Date: 2009-02-01 20:44:26

> > 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

Totally agree. An uniformed standard on coding, performance, compatibility
and doc 
is important.

B/Rgds
Max