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.