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/