On 07-Jul-15 2:56 PM, Niall Douglas wrote:
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
There is a number of existing Boost libraries, and other open-source projects, whose quality is quite excellent despite having no per-commit CI - for example because the maintainer has more compilers installed locally, and more virtual machines, than all cloud CI systems combined. Calling these maintainers retrograde is hardly appropriate. Thanks, Volodya