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

Subject: Re: [boost] Once accepted, when does a library undergo further review?
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2014-01-04 06:06:25

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Edward Diener
> Sent: Saturday, January 04, 2014 7:10 AM
> To: boost_at_[hidden]
> 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_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.

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
[phone]  07714330204
pbristow_at_[hidden]