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

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Edward Diener Sent: Saturday, January 04, 2014 7:10 AM To: boost@lists.boost.org Subject: Re: [boost] Once accepted, when does a library undergo further review?

On 1/3/2014 11:56 PM, Richard wrote:

...

[Please do not mail me a copy of your followup]

boost@lists.boost.org spake the secret code thusly:

...

On Fri, Jan 3, 2014 at 12:31 PM, Richard 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.

I don't disagree with this - except that Boost.Test is a special case. It is pretty important that we are all singing on the same hymn sheet when it comes to testing. Changing Boost.Test always risks mucking up nearly everyone's testing, never popular! Creating Boost.SonOfTest is possible but risks confusion. Can I suggest that Boost.Test be placed in 'community care'? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com