On 04/02/2015 04:13 PM, Niall Douglas wrote:
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.
It would seem that automatic scoring of libraries is both hard technically, and likely to result in arguments.
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.
While Travis is a convenient tool for some purposes, it's just tool to run scripts on commits. Having .travis.yml in a repository does not say much about the quality of the code per se. Did you mean a more specific suggestion? Also, it does not support Windows, for all I know, whereas Boost is all about portable C++, which very much includes Windows. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com