Re: [boost] Boost summer of formal reviews

Subject: Re: [boost] Boost summer of formal reviews
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-03-11 15:47:00

On 11 Mar 2014 at 17:57, Borislav Stanimirov wrote:

> Well I am not familiar with all ideas that have been given and the 
> following could have been mentioned before (and even shown to be bad), 
> but what about openly accepting donations for Boost and using them to 
> actually pay the review managers for their time.

That would raise a legal minefield. Boost would have to register as 
an employer and deduct taxes etc.

> Apart from that, what is the actual risk of adding a bad library to the 
> collection?

Surprisingly high. Even if a library ticked all the boxes in that 
list I provided earlier, for example TypeIndex v2.0 had a dangerous 
undefined behaviour in it that both myself and Antony missed before 
bringing it for review here. That UB compiled and worked fine on all 
present compiler technologies, but could have caused significant 
problems if say Reflection entered the C++ language in some years 
time.

> The following is an idea for a fundamental change in the review process:
> 
> * Have a short informal review process based on short reviews from the 
> community. More than a spam filter than an actual review process, 
> actually. The "reviews" could be something like "Well. It looks OK to me".

We already have that. I posted asking for a mini design review only 
last week.

> * Then have an _automated_ test for eligibility. Does the library 
> compile as part of Boost in the most popular compilers and 
> configurations? Static and dynamic analyzers can provide code coverage 
> info by the library's tests (100% would be a requirement). They will 
> check whether it crashes, has memory leaks, and more.

On this I very much agree, and I listed some good criteria in an 
earlier post.

> * After a library passes the automated tests, it just becomes a part of 
> boost. _BUT!_ It does so in the namespace boost::bleeding_edge. Have a 
> disclaimer that bleeding_edge libraries haven't passed a formal review 
> yet. Still, even with such a disclaimer, they would be exposed to the 
> public, and more people would be encouraged to try them.

I would be wary to diminishing the Boost brand by distributing 
non-peer reviewed libraries in the main distro. I wouldn't oppose a 
secondary "add on" distro containing libraries in the review queue 
which have passed the metrics in my previous post, but I still think 
that passing peer review is what makes Boost Boost. If you don't pass 
peer review, you can't say you're a Boost library.

> * To get out of the bleeding_edge namespace, a library needs to either 
> receive a formal review (in the format formal reviews are made now), or 
> demonstrate its use in several real-life working projects (independent 
> from the author).

To get a willing peer review manager a library already needs to 
become popular enough, so we already have that too. For example, not 
enough people are using AFIO, therefore no one wants to peer review 
manage it, therefore I agree AFIO should not enter Boost until it is 
popular enough - after all, no one may be using it because it has an 
awful unintuitive design irrespective of technical merit :) Equally, 
it simply may be a useless library and solves no real problem, 
another good reason it should not enter Boost.

Niall

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