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-04-02 09:13:09
On 1 Apr 2015 at 23:31, John Phillips wrote:
> 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.
I had thought that the historical placeholder page was
Whereas the page at
http://www.boost.org/community/review_schedule.html was for
supposedly "Boost ready" libraries?
> 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.
I would far prefer a scoreboard based system which shows a ranked
list of libraries by quality score. Auto generated from a database,
I also think that Boost 2.0 should be about being a single stop
portal for "Boost quality" libraries rather than Boost libraries. I
was recently working with eggs.variant for example, and that is Boost
quality written to Boost guidelines and yet I understand there is
zero interest in it entering Boost, despite it being superior to
Boost.Variant in almost every way. Same goes for HPX and plenty more.
Anyway, I'll elaborate during the Boost 2.0 talk.
> 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.
Requiring Travis support does not cause the exclusion of any other
form of testing, it just sets an absolute minimum bar to pass - a
minimum bar that I might add is increasingly becoming the bar for ALL
open source projects, so by not requiring it Boost looks behind the
times to the wider open source community. It does require people to
use github which is a bit locked in alright, but the huge advantage
of git is that you can have github auto mirror a git repo elsewhere
to avail of the github-specific free tooling.
> 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.
By the end of this week I'll post the list of forthcoming C++ 11/14
only Boost libraries I'll be reviewing in my C++ Now talk. I am
currently building a "traffic light" matrix of "Boost readiness" of
the C++ 11/14 only libraries that I know of ordered by closeness to
entering Boost. I think it'll be surprisingly interesting to the
list, I was a bit surprised myself.
What would be really great is if the formal review schedule at
http://www.boost.org/community/review_schedule.html could be enhanced
to also show the same traffic light matrix of "Boost readiness" of
its entrants. Actually, I'd personally like such a traffic light
matrix for *all* Boost libraries, because it would illuminate just
how badly maintained some of them are (and hopefully encourage their
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk