[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"? -- "The Direct3D Graphics Pipeline" free book http://tinyurl.com/d3d-pipeline The Computer Graphics Museum http://computergraphicsmuseum.org The Terminals Wiki http://terminals.classiccmp.org Legalize Adulthood! (my blog) http://legalizeadulthood.wordpress.com

-----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

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/

On Jan 6, 2014, at 2:33 PM, Nevin Liber wrote:

On 4 January 2014 11:34, Niall Douglas wrote:

...

Also, more controversial features, techniques or ideas which wouldn't pass peer review are deliberately kept till after admission.

Do you have an example of this?

I can only suppose that AFIO will be such a library if it should pass review some day, and that makes me uncomfortable.

IMHO, this seems like it would be an abuse of the trust given to Boost developers.

Thanks, Nevin. I was planning a similar reply. ___ Rob (Sent from my portable computation engine)

On 6 Jan 2014 at 13:33, Nevin Liber wrote:

...

Also, more controversial features, techniques or ideas which wouldn't pass peer review are deliberately kept till after admission.

Do you have an example of this?

Well, I'm not going to name names when anyone interested can search this list's historical archives for when people complain loudly about changes. There is a library whose internals have seen a lot of recent and radical change, and it regularly breaks AFIO. I'm not alone in experiencing such breakage, but personally speaking I support such changes as they are a positive thing, even with the extra work they cause me in keeping up.

IMHO, this seems like it would be an abuse of the trust given to Boost developers.

I would call it a *consequence* of the trust given to Boost developers. They earned that trust by achieving passing peer review, a no small feat. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/