Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-05-17 06:45:37

On Friday 16 May 2014 11:10:51 Niall Douglas wrote:
> 
> 1. Boost isn't sexy any more. As one very highly respected world
> famous engineer put it - and I won't say who, and I apologise to him
> for stealing his words without attribution:
> 
> "Boost used to be about all the stuff you really wanted in the
> standard. Now Boost looks like all the stuff that wasn't good enough
> to get into the standard"

I disagree with it completely and fighting the urge to use the word 
"ridiculous". There are no tools like Boost.Intrusive, Boost.Spirit, 
Boost.Interprocess or Boost.ASIO, not to mention things like XML, advanced 
networking (HTTP, FTP, SSL, etc.), encryption, the holy grail of GUI and many 
other domains not covered by Boost. You got threading, regex and a couple new 
containers and think you're covered? I think the previously hopelessly lacking 
STL got a little less hopelessly lacking.

Granted, some of these (networking and filesystem) are making their way into 
the language. Others I don't see coming (I'm looking at Boost.Intrusive and 
Boost.Spirit in particular), and I'm using these tools almost on a daily 
basis. I find myself using Boost.Intrusive by default instead of STL 
containers whenever the situation requires something more complex than a 
vector. And when I occasionally have to write Java code I find C++ pretty damn 
sexy.

> 2. Everyone recognises there are serious problems with process,
> everything from how you were treated Stephen when you tried cleaning
> out cruft and only really Dave supported you, right through to the
> fact that peer review simply doesn't work any more. The Boost
> community has become quite selfish in recent years, as you would
> expect from those with a vested interest in the status quo before
> evolution. And for the record, I have no problem with those vested
> interests keeping their existing Boost, but I personally want as far
> away from C++ 03 as soon as is possible.

I'm sure I'm not reading you right because calling people selfish for writing 
quality code for public use and providing support for free doesn't make sense 
to me and verges on an insult.

What I see is lack of involvement of the community in Boost as a whole. This 
includes the lack of reviews and review managers, the lack of responses to 
list and support queries. With all its positive sides, the modularization 
increased that negative effect because now people don't have full access to 
the repository and therefore have less means and will to influence. I suppose, 
that is expected and eventually Boost will become just a label for many 
separate projects (that are currently libraries) with their own sub-
communities. Not necessarily a bad thing, but it is sad to see that the Boost 
project as a whole fades. I do not see how your proposal changes that, rather 
the opposite.

> 3. All the interesting new C++ 11 libraries you find around the
> internet have zero interest in trying to join Boost, with a very few
> honorable exceptions. That speaks volumes, to me at least.

I see no problem with that. Boost was never the only library in the world, not 
in C++98/03 times, not now.

> And here is what I think should be in a fork of Boost:
> 
> 1. Minimum required compiler feature set will be VS2014's. No use of
> Boost STL permitted where the C++ 11 STL provides a feature.

What if Boost implementation is better? E.g. Boost.Regex is considerably 
faster than std::regex (both MSVC and libc++).

What if Boost implementation provides extensions that are not available in 
STL? E.g. Boost.Atomic will provide additional operations and Boost.Thread has 
synchronization primitives that are not standard.

What if a library wants to be compatible with C++03 as well? Is it banned? 
Does it have to duplicate the missing components within its own scope?

> 2. cmake instead of Boost.Build.

Cmake is not ideal, but I admit I feel more comfortable with it than with 
Boost.Build.

> 3. Eliminate peer review in favour of a suite of automated libclang
> based AST analysers. Instead of persuading people to review
> libraries, persuade them to review and improve the AST analysers.

This is where you say that Boost (as a whole project) community is no longer 
needed. No AST will be able to evaluate the design and usability of a new 
library and its documentation. Peer review, especially for the new libraries, 
is absolutely needed, IMO. I would say that major changes to the accepted 
libraries also need to be reviewed. Unfortunately, the practice shows little 
interest for that in the community. But even then I believe that reviews is a 
positive and essential part of ensuring the code quality.

I understand that the current scheme of reviews is holding back the growth of 
Boost. As I said, it is sad to see the lack of involvement of the community. 
But replacing the review process with an automated check is not the answer. I 
don't have the answer myself, but I can say that I want my code to be reviewed 
and I want to be sure that others' code is reviewed before it enters Boost (or 
at least receives some official status). Otherwise I don't trust the code 
quality, however contrived automated checks you run on it.

> 4. Mandatory cross platform per-commit CI with unit testing exceeding
> 95% coverage. We don't care what unit test library is used so long as
> it can output results Jenkins can understand.
> 
> 5. Mandatory all green thread, memory, UB sanitisers and clean
> valgrind. All also tested per-commit.
> 
> 6. Mandatory CI testing for exception safety. I am hoping a clang
> rewriter can basically patch all exception throws and have them
> randomly throw for testing.

Any improvement of the testing infrastructure can be only welcomed on my side. 

Although I wouldn't set any mandatory bar on the coverage. There are cases 
which are difficult or even impossible to test within the automated testing 
environment. This includes long-running tests, platform-specific code and 
functionality involving third party components. A library should not be 
forever banned if some parts of it cannot be tested in the CI.

> 7. Per-library source distributions instead of a monolithic blob.
> This implies some dependency management, but cmake makes that much
> easier. It also means we can eliminate the release cycle because each
> library does its own release cycle, and the correct (i.e. tested)
> version of dependencies are included into each per-library source
> distro. This solves the version lock problem currently plaguing
> git-ised Boost, at the cost of pushing the version lock problem onto
> users [1]. BTW I want to see a soak test of the unit tests for 24
> hours be all green before a release.

I think there should be a way to generate a monolithic distribution, even if 
from separate packages. The dependencies between packages (of some select 
versions) should allow that. This will make it easier for downstream package 
maintainers to build and distribute a slice of Boost libraries compatible with 
each other.

> 8. Reusable utilities in a submitted library need merging into some
> common utilities library which follows the STL conventions. Other
> than that, no source code, naming conventions, namespace or anything
> else needs converting or changing. We are looking for very high
> quality C++ libraries, nothing more. Obviously if someone hopes for a
> library to enter the C++ 17 STL they'll need much more rigour, but
> that's up to them.

That utilities library should not become a zoo of namespaces and similar but 
different components. So some conversion and documentation will be required. 
Also there is an issue with dependencies of these utilities on other 
libraries. This is something we're trying to address with Boost.Utility now. 
Other than that I agree, the less code duplication the better. 

> 9. There is no longer an "in" or an "out" for distribution. I'm
> thinking of a scorecard page where member libraries are ranked by how
> high quality they are according to all the automated review, so when
> I say "mandatory" above, I simply mean they don't get to appear on
> the main downloads page without that precondition. All submitted
> libraries do appear though, just ranked very low if their quality is
> low. I would hope all this is generated from a database and requires
> very little human input.

I don't understand. Do all libraries appear in the downloads or do some of 
them not?

> 10. BoostBook documentation using the Boost look and feel becomes
> mandatory. I've had enough with library authors thinking they can
> improve on BoostBook's output with things like using Comic Sans as
> the font or weird colour schemes throughout.

I'd change the preference to QuickBook. Writing and maintaining raw BoostBook 
is... counterproductive. Also, the requirement should be on the look and feel 
and not the particular toolset you use to achieve that.