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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-03-30 22:17:37

On 30 Mar 2015 at 18:33, Robert Ramey wrote:

> Insisting on the above would be a significant policy change for Boost.

I think the policy that libraries in the review queue are maintained 
has always been policy as we don't admit unmaintained libraries to 
Boost. In fact, to my knowledge, we don't (or haven't ever) even 
admit libraries maintained by non-individuals. The introduction of 
the CMT was to my knowledge the first time a non individual person 
ever maintained a Boost library.

I therefore think that the review queue should be purged of 
unmaintained libraries appropriately. Once the authors have been 
notified and given a chance to update their submissions of course.

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

As I mentioned, the newer libraries in the queue mostly have Travis 
enabled (from my quick scan), so it appears it's happening anyway for 
new libraries. Some of the libraries in the queue have been there for 
many years now, but their maintainers have done a great job keeping 
them up to date. QVM and Nowide are amongst the oldest, yet are well 
maintained - for example Nowide just gained a STL11 only 
implementation, so no more Boost dependency.

I think after a purge of the unmaintained libraries, requiring Travis 
CI testing might only affect three to four libraries in there, two of 
which I just mentioned. The bigger ask than Travis support might 
actually be the ask of putting their submissions onto github as 
travis doesn't work well with non-github for open source projects.

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

Travis only has four big pros:

1. It's free of cost.

2. It is very flexible, if awkward. Want to test some weird version 
of Boost with some weird version of libstdc++ and do a curl push of 
results to some RESTful API on your own custom server farm? No 
problem.

3. It's the only access to OS X CI testing for almost everyone as OS 
X costs a bomb for licensing. BTW, I developed a system for remotely 
debugging a segfaulting OS X unit test on Travis, anyone who needs it 
ping me.

4. It's very well integrated with other open source CI web tooling 
such as Coveralls. CI status integration with github, especially pull 
requests, is excellent.

Everything else about Travis is negative compared to alternatives, 
including a lousy UI which gets fussy very quickly, and no (easy) way 
of debugging except endless git commit and push cycles.

That said, for testing it compiles and passes unit tests for some 
recent clang + GCC + Boost, it really is very good indeed. If you're 
already on github and your Boost library is modular, it's a few hours 
of your time at most.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/