Boost logo

Boost :

Subject: Re: [boost] Once accepted, when does a library undergo further review?
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-01-04 02:09:47

On 1/3/2014 11:56 PM, Richard wrote:
> [Please do not mail me a copy of your followup]
> boost_at_[hidden] spake the secret code
> <CAAygHNN5K_G55W8PH6uLHD5aXQOoZChA=2ianHR8dW89RMj36w_at_[hidden]> thusly:
>> On Fri, Jan 3, 2014 at 12:31 PM, Richard
>> <legalize+jeeves_at_[hidden]>wrote:
>>> However, once a library has been accepted, it doesn't seem to go
>>> through any more peer review.
>> That depends on the conditions attached to acceptance by the review
>> manager. [...]
> I'm talking about after everything required by it's initial review has
> been completed and submitted.
> ...but the maintainer can still make commits to the library and do
> things in this subsequent phase that never would have been accepted in
> the original review.
> Things like poor or missing documentation.
> Things like reinventing the wheel for supporting classes that are not
> the main focus of the library and are provided by other boost
> libraries.
> Things like egregious overuse of macros or other coding practices that
> are considered poor form in modern C++.
> In other words, once a library has been accepted into Boost, what
> prevents that library from suffering from "code rot"?

As a Boost library developer I would not want others looking at every
change I might make to my library and passing judgment on those changes.
OTOH others are free to make suggestions and point out errors. Similar I
would be free to discuss proposed changes to my library and see what
others think.

I understand your frustration if you are involved with a library which
you may feel is not being maintained properly, but you are always free
to create another library of similar functionality which you feel is a
better implementation than what has already been accepted into Boost and
submit it for review. Occasionally such a process, without being
derogatory to the original library, actually leads to a more useful
alternative in Boost.

Alternatively you can ask the current maintainer if you can also make
changes to his library based on the better implementation which you
think you have. This can be through a fork of his library and pull
requests, or can be by becoming a member of that library's team.

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