On 7 Jul 2015 at 9:50, Vladimir Prus wrote:
Regarding these particular conditions, to avoid surprises I should say that all of them are reasonable, but don't necessary qualify as hard preconditions.
Say, having no Boost dependencies might be good for some users, but having 'no Boost dependencies' as hard requirement for accepting a Boost library is not very logical.
I can agree with this. It's more a usability/user friendliness thing really, plus some corporations explicitly ban any library with the word "Boost" in its title, so if you can make your library standalone it will gain a not insigificant increase in potentially paying userbase.
Likewise, CI is a good thing, but not accepting a library for lack of CI will be unfair to the library author, and requiring a particular CI service will be unnecessary promotion.
I profoundly disagree on the first point. Any new library should be using a per-commit CI period. The fact such services are free, and they make such an enormous improvement to github pull requests and not breaking build accidentally make them one of the key quality and productivity leap forwards of the past decade. To not have your library per-commit CI enabled is enormously retrograde, and if a library before review here refused to have some per-commit CI in place I would vote for rejection personally because such a library could never be of Boost quality. On the second point, of promoting one service over another, for sure it'd be great if Boost provided a common Jenkins CI for all Boost libraries. We don't, so until then the most popular free CI by a long shot are Travis for Linux and OS X and Appveyor for Windows. It's hard to not promote a service when those two are so utterly dominant in open source. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/