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: Robert Ramey (ramey_at_[hidden])
Date: 2015-03-30 21:33:52

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.

> I might add that all the very recently added libraries to the queue I 
> examined _do_ use Travis, though to what depth I do not know. 
> Nevertheless, I find this a very welcome improvement that many of the 
> official Boost libraries could do with.

I'm certainly in favor of improving our testing coverage.  But I'm
not convinced that travis is the way to do it.  In any case, this would
be a separate topic (I think).

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/peer-review-queue-tardiness-Cleaning-out-the-Boost-review-queue-tp4673913p4673939.html
Sent from the Boost - Dev mailing list archive at Nabble.com.