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 https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries? 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, of course. 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 timely removal). Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/