Re: [boost] Once accepted, when does a library undergo further review?

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.