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

Subject: Re: [boost] Once accepted, when does a library undergo further review?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-01-04 12:34:52

On 4 Jan 2014 at 4:56, Richard wrote:

> >> However, once a library has been accepted, it doesn't seem to go
> >> through any more peer review.
> >
> 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.

That ability is both a feature and a bug. After you're into Boost, 
it's basically an honour system whether you ask for peer review of 
any major changes where the maintainer decides alone what is "major".

I think this system has worked pretty well to date, much better than 
other parts of Boost's processes.

> Things like poor or missing documentation.

Peer review has been too lenient on crappy Boost documentation in the 
past, but much less so recently. Once documentation is excellent, 
it's much easier to keep it excellent over time. Getting it excellent 
is a huge amount of work, even for small libraries. AFIO took as much 
effort in man hours to write the docs as it did to write and debug 
the code, and that's probably about the right proportion.

> Things like reinventing the wheel for supporting classes that are not
> the main focus of the library and are provided by other boost
> libraries.

Reinventing boilerplate is very hard to avoid in practice because it 
requires other people to do things in a timely fashion, and it's 
almost always easier to do it yourself than bug people for changes 
and then wait around until they're done. AFIO reinvents many wheels 
already reinvented many times throughout Boost, and it's a brand new 
library still awaiting peer review, and I *knew* I was reinventing 
wheels because I studied the originals during my reinventions.

So why did I do it? Simple: it was easier and faster, and it removed 
dependencies on other libraries which would have been there purely 
for reuse of boilerplate.

Many Boost libraries also began life outside of Boost, and therefore 
bring in boilerplate from other, older libraries rather than use 
Boost facilities. All that ends up buried in the detail directory. 
Most would prefer that weren't the case, but it's a time and 
resources thing - it's faster to bundle a copy of the boilerplate 
than rewrite it.

> Things like egregious overuse of macros or other coding practices that
> are considered poor form in modern C++.

I say meh to most of that. If a practice internal to a library 
doesn't affect external code and users, who really cares? [1]

> In other words, once a library has been accepted into Boost, what
> prevents that library from suffering from "code rot"?

Most code rot in Boost is from *lack* of change, not too much change. 
As much as it sucks when changes in Boost libraries break my code, I 
lose more productivity to lack of changes in Boost libraries than 
changes.

Also, more controversial features, techniques or ideas which wouldn't 
pass peer review are deliberately kept till after admission. I think 
that's the prize that you "win" by demonstrating to the Boost 
community that you have what it takes to pass peer review. Once 
you've demonstrated that capability, you *earn* the right to be more 
experimental if you choose. I certainly know that what I have planned 
for AFIO after peer review would never pass peer review if I 
implemented it now.

[1]: My personal opinion only. I know plenty of people on this list 
would strongly disagree.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/