Boost logo

Boost :

Subject: Re: [boost] Boost.DLL formal review is ongoing
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-07-07 07:56:45

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

> 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.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at