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/