Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries

Subject: Re: [boost] Some statistics about the C++ 11/14 mandatory Boost libraries
From: Vladimir Prus (vladimir.prus_at_[hidden])
Date: 2015-05-13 23:58:22

Niall,

On 05/13/2015 07:19 PM, Niall Douglas wrote:
> Tomorrow at 11am after Eric's talk I'll be presenting at C++ Now a
> review of the upcoming C++ 11/14 mandatory Boost libraries. I looked
> at fifteen libraries and decided ten were worth further
> investigation. I'm sure you all remember my colour coded ranking of
> those ten libraries by "nearness" to entering Boost:
>
> https://goo.gl/6l1KiH

Looking at this list, I have a few questions:

- Why is that future directions of Boost must be determined by only C++ 11/14
   libraries?

- 5 of the libraries are not in the review queue. Why is that future direction
   of Boost must be determined by libraries that are not actually proposed?

- Many of them are marked as not supporting MSVC. Not even 2015. That sounds
   a rather unpractical attitude, and makes me wonder, again, why would we use
   data from these libraries to decide on any future plans?

> I sadly only have time to review four of those libraries during my
> talk, but one (APIBind) enables an alternative Boost 2.0 approach and
> I will spend 45 mins on that library alone. And here is my
> alternative Boost 2.0 vision:
>
> Boost 2.0 is a alternative distro of modular standalone Boost
> libraries which can be each downloaded separately. Each has
> contemporary per commit CI testing and is nightly dashboarded by
> quality score by a web service under the 19 quality score headings
> listed at https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook
> (still unfinished, but nearly there).
>
> APIBind allows the library end user to dependency inject what
> dependencies that library uses. This allows a Boost library, in a
> single codebase, to be part of both the monolithic Boost 1.x distro
> and to be modular and standalone and part of the Boost 2.x distro.
> Motivated library maintainers port their Boost 1.x library to the
> APIBind platform, and therefore can be part of both 1.x and 2.x
> distros if they want.
>
> Those libraries not ported to APIBind remain in the 1.x distro, which
> I would assume will gradually fade into obsolescence over time. This
> makes sense, as if a maintainer is not motivated to do the port then
> it seems proper that library should gracefully deprecate.
>

I am not sure exactly what you mean by 'ported'. If you propose that
maintainers need to invest time in make a perfectly working library
be part of your "Boost 2.0", then it's a bad idea, sort of
fire-and-motion strategy (http://www.joelonsoftware.com/articles/fog0000000339.html)

> There is some empirical data supporting the inevitability of this
> alternative vision of Boost 2.0. Of the ten libraries I examined in
> any detail:
>
> * Just 1.5 libraries have any dependencies on Boost headers at all
> (the 0.5 is because that library is currently removing its Boost
> dependencies).
>
> * Just 3 libraries can use Boost.Test.
>
> * Just 3 libraries use Boost Docs.
>
> * Just 2 libraries require using Boost.Build. The rest are header
> only, or use cmake.
>
> * Just 6 libraries use Travis/Appveyor for free CI testing on Linux,
> OS X and Windows.
>
> * Just 3 libraries use valgrind as part of their unit testing (two
> are mine!).
>
> * Just 3 libraries use coveralls for coverage reporting (two are
> mine!).
>
> Personally speaking, I think the new library authors are
> overwhelmingly voting for a complete break with Boost 1.x. It makes
> no sense to bundle these new libraries into a 1.x monolithic distro
> when they have no dependencies on Boost.

I think this statement is unfounded. Rather, it's correct to say that
there exist 10 libraries with "Boost" in name, hand-picked by you,
9 of them not official Boost libraries, and 5 of them not formally
proposed and 3 of them not even ready source-code-wise, and:

- Most are header only
- Most don't depend on other Boost libraries
- Many don't work on Visual Studio

> I believe now is the time we start establishing the infrastructure to
> shape the new Boost 2.0 distro instead of wasting resources on trying
> to refactor the 1.x distro. APIBind is there for maintainers wanting
> to be part of both distros. Let's make a clean break.

While the above are interesting findings, I don't think they logically
mean that authors of these libraries are voting for your infrastructure?
Nor does that mean other libraries should make any changes.

-- 
Vladimir Prus
CodeSourcery / Mentor Embedded
http://vladimirprus.com