On 14 Jul 2015 at 10:07, Vladimir Prus wrote:
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.
Firstly, my comment was qualified with the qualifier "new libraries". Secondly, you appear to be confusing integration testing with continuous testing. The former is of the type you mention, the latter can be as simple as a simple "does the library and its testsuite compile without warnings, static warnings nor errors on 80% of compilers and platforms?" I would challenge any Boost library maintainer to fail to add a simple "does it build?" Travis CI per commit test in any time amount exceeding one hour, especially now Travis has just added the new opt-in super fast Amazon EC2 instance support which is breathtakingly fast. With a second hour they can patch in per-commit clang-tidy, clang static analyser and MSVC static analyser support too. Antony has coverity-scan in his as well, I personally found it chokes badly on AFIO code and coverity officially refused to fix their tool. Still, could be useful for some. Thirdly, you are not adding per-commit CI testing for yourself. You are adding it for *everybody* *else* specifically anyone who forks your library on github, fixes a bug and sends you a pull request. *They* are the people you add per-commit CI testing for, not you. It's for this reason that AFIO is CI tested both by Jenkins (for me with full fat testing) and by Travis and Appveyor (for anyone who forks AFIO with "did you break me?" testing).
Calling these maintainers retrograde is hardly appropriate.
The best description is "anti-social" as David Sankel would put it. It's also a question of branding and marketing, as having CI status badges on your github project sends a strong easily recognised signal that you care about quality. For the minimal effort involved to add support, it's a no-brainer. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/