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