Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements

Subject: Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements
From: John Phillips (johnphillipsithaca_at_[hidden])
Date: 2015-04-01 23:31:47

On 03/30/2015 09:33 PM, Robert Ramey wrote:
> Niall Douglas wrote
>> On 30 Mar 2015 at 15:41, Robert Ramey wrote:
>>
>>> FWIW Block pointer and Process can be found in the incubator.  I'm
>>> guessing
>>> that the authors haven't totally given up hope.  Array? isn't that a
>>> boost
>>> library (and now a standard library component) already?
>>
>> I believe that libraries in the review queue ought to be "Boost
>> ready", and if they are not then they should not be in the queue.
>> That means:
>>
>> 1. Configured as a Boost module according to modular Boost. Any
>> library not updated since the 1.56 release which was the first
>> modular release surely fails this.
>>
>> 2. Known to be working perfectly and passing all unit tests on recent
>> compilers configured into C++ 11 and C++ 14 modes.
>>
>> 3. Known to be working perfectly and passing all unit tests with the
>> latest Boost release.
>>
>> As you know Robert, I would personally make it mandatory for Travis
>> CI to be testing the above three requirements per commit against
>> latest Boost if a library wishes to be in the review queue (actually
>> I'd ask for a whole lot more, but it isn't as free of cost as
>> Travis). I don't think this asks much of the author. Antony has done
>> a great job at making a generic Travis script for Boost libraries
>> which just drops in ready to go.
>
> Insisting on the above would be a significant policy change for Boost.
> "Cleaning out the Review Queue" based on this policy would be
> quite a change.  I would like to hear what the Review Wizard
> and other members of the boost community think about this.  I
> don't think anyone can impose such a change unilaterally.
>...
> Robert Ramey

   I think I can speak for both Ron and myself when I say that our 
opinion has been that we run the review system the Boost community wants 
to have much more than we decide what the review system should be.

   Historically, we have long had libraries that were in the queue, but 
not scheduled for a review, that were not yet Boost ready. In a sense 
they were placeholders that made it clear someone was trying to create a 
library for task X. The queue was where they could be visible to a large 
fraction of the community and start discussions about implementation 
decisions and other useful questions.

   The more recent creation of the incubator probably makes this 
practice outdated, and I expect newer libraries under development will 
receive more valuable attention in the incubator than in the queue. As a 
community member, I would support moving such libraries out of the queue 
and into the incubator, but preferably with developer agreement.

   Testing policy is a more difficult question in my mind. It has not 
been the history of Boost to require any specific testing infrastructure 
(or most other sorts of infrastructure) for libraries. There have been 
times when this non-requirement has increased complexity, but there have 
also been times when experimentation has found better solutions. As a 
community member, I'm wary of forcing standardization, and would need 
some pretty persuasive arguments to support it.

   One thing I strongly support is community discussions on how to 
improve our review process. Thanks to Niall for starting one, and to all 
the other participants, as well.

                        John Phillips	
                        Review Wizard