Subject: Re: [boost] Boost.DLL formal review is ongoing
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-14 06:31:42
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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk