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/