Re: [boost] Boost.DLL formal review is ongoing

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/