Boost logo

Boost :

Subject: Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2010-02-23 18:02:21

Simonson, Lucanus J wrote:

> He must be comparing it to something else that is faster, like getting new features into the linux kernel...

I'm comparing it to what I'd like it to be.
I don't think that because some high-quality successful projects use
certain management techniques that it's necessarily the best ones to
follow in all situations.

> I think if people used the pace of the C++ standardization system as a baseline for comparison they would find that boost is extremely fast paced and exciting.

When the libraries that provide workarounds for the lack of certain
future C++0x facilities probably won't be included until after the C++0x
standard is released and well implemented, you could ask yourself if
that really is the case.

> People who propose a library to boost should frankly expect determining interest, iterative revision, review, acceptance and release of a library to take years (literally). Perhaps we should put a warning to that effect in the description of the process on the web site so that it doesn't come as a surprise every time. I didn't mind because it took nine months (literally) just to get permission from my employer to open source my code. By comparision the boost review process was quite reasonable. Actually there are some steps to the open source permission process I went through that might be reasonably added to the boost review process, like running protexIp on libraries under review to make sure that they aren't infringing anyone's copyright, which could expose users of boost libraries
> to liability.
> There are benefits to a slower paced review and acceptance process. If a library author shows the perseverance to get through the review process and get their library into a boost release they have usually demonstrated the dedication required to maintain the library for at least several years to come. We already have several libraries abandoned after acceptance but before release sitting in limbo. If anyone could come along, propose a worthy library and get it accepted in a few weeks then how many unmaintained libraries would we have in boost after only a couple years? Is that what we want? Steven Watanabe can only maintain a hundred or so orphaned boost libraries before his youthful energy will be exhausted and then what will we do? We need more than libraries in boost, we need acti
> ve community members too.

I think there are different situations, and more importantly different
types of libraries within Boost.
Please note that what follows is my (potentially naive) opinion, and
does not necessarily reflect that of the Boost community.

Certain libraries exist by themselves and are pretty much big standalone
entities, including Polygon.
Others are pretty much just programming tools, that are also more prone
to coupling.

I would say that the majority of the libraries in the current review
queue falls under the second category, and should be reviewed
differently from the rest, on a fast-track.

While I agree the slow paced review is good for large standalone
libraries, it is hurting tools because, since they're pretty much very
general and small, people -- and by people, I mean both boost users and
developers -- tend to rewrite them when they need them, which causes
duplication and maintenance issues.
While for a large library, you would choose to use it or not at the
beginning of a project (or at an important decision-making step), a tool
you would just come to use when the need to do so arises.
What makes Boost popular is really that it has versatile tools for
everyday C++ programming problems -- which is often achieved through
generic programming -- as well as operating system abstractions that are
pleasable from a C++ point of view. It also provides finely crafted
libraries covering specific problem domains, but they're often as much
popular by themselves than by being part of Boost.

A tool for a specific task in Boost also means that the tool is a
recommended way -- with its trade-offs, of course -- to perform that
task, and thus contributes to some kind of unified vision of modern C++
programming that Boost is envisioning by being the testbed for the
standards to come.

Of course, the line between the two categories are much more fuzzy than
I just made them appear to be with my nice tirade.

Boost list run by bdawes at, gregod at, cpdaniel at, john at