Re: [boost] review system in place is extremely slow? (was Re: [rfc] rcpp)

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.