Re: [boost] Thoughts on Boost v2

Subject: Re: [boost] Thoughts on Boost v2
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2014-05-16 13:49:18

Niall,

I agree with your analysis, and to some degree with your conclusions /
proposal. See below.

On 05/16/2014 01:10 PM, Niall Douglas wrote:
> On 16 May 2014 at 17:46, Stephen Kelly wrote:
>
>> There is clearly not agreement within Boost that anything should be done at 
>> all regarding modularization, before a more 'big bang' break forward, from a 
>> reading of the mail from Niall.
> For the purposes of clarity, I am not a member of Boost. I do not sit 
> on any committees, and have no representation nor standing with the 
> community apart from doing some admin for GSoC. I would say that my 
> opinions on this are so extreme that no one agrees with me, and I 
> expect my presentation at C++ Now tomorrow to not be popular.
>
> I have however been doing a lot of canvassing whilst here at C++ Now. 
> The main problems with Boost which are causing its decline are these:
>
> 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"
>
>
> 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.
>
>
> 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.
>
>
> Which suggests to me a need for a new Boost which attempts to apply 
> the benefits of hindsight to what we learned with Boost v1. Now, it 
> is extremely clear from this conference there is little appetite for 
> that, but I think later on this year we're going to have three C++11 
> libraries in the queue, and if things have not very significantly 
> progressed in any of the three items above, I think that time will be 
> right time to fork. 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.
>
> 2. cmake instead of 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> So, basically, in some areas requirements are significantly 
> tightened. In other areas requirements are significantly loosened. 
> The aims of the above ten items are as follows:
>
> 1. To reduce the amount of human work involved in maintaining Boost. 
> What Dave and Daniel had to do for the git conversion last year was 
> far above what anyone should ever feel they need to do.
>
> 2. To decentralise Boost, letting it scale up far better.
>
> 3. To provide a gradual process of entering Boost which authors can 
> tip away at slowly with automated scripts slowly improving their 
> rankings instead of the current "lumps" of high intensity output and 
> the review approved/failed scheme currently used.
>
> 4. To incentivise authors to maintain their libraries as the quality 
> bar is improved - the automated scripts will start to drop library 
> rankings as the quality is raised, thus dropping that library in the 
> overall rankings. Rather more importantly, it provides a natural 
> "deprecation" mechanism, something sorely lacking in my opinion from 
> present Boost.
>
>
> Thoughts?

My main point of contention is your emphasis on a mandatory set of rules
/ policies. I think the level of modularization needs to be pushed much
further than to exclusively focus on source code layout (and revision
control). The problem isn't really technical, but social: For example,
we engineers love to spend countless hours on tools and infrastructure,
and as a result each suggestion to improve anything in that area draws a
huge amount of attention and energy.
Why not let each library have their own choice of build tool,
documentation format, etc. ? All dependencies need to be explicitly
spelled out, not at the file level, but the package level, so building
library X shouldn't need to be concerned at all about how its
prerequisite library Y was produced (, documented, etc.).
It's of course fine to propose certain tools if they are proven to work
well. But trying to come up with a unified development environment (a la
RYPPL) just seems an invitation for another stall.

In such a world "Boost" merely becomes an umbrella organization with
some administrative, legal, etc. assistance. Criteria for acceptance
shouldn't be based on what development environment developers choose, so
long as certain criteria (license, code quality, etc.) are met and the
project's goal / focus fit into Boost. Needless to say, each library
would have its own release cycle, and dependencies to other boost
libraries should take versions into account, to provide maximum
independence and help packagers.

No need for a central review or release management.

    Stefan

>
> [1]: If this model proves popular as we can get a regular donation 
> stream going, we could deploy an automated SHA stamper which through 
> unit test iteration, figures out which SHAs in which combinations of 
> libraries are compatible. Then you could safely mix library A's 
> distro with library B's distro. I'd imagine Debian upstream et al 
> might be coaxed into providing for this as they need one unified set 
> of compatible libraries.
>
> Niall
>
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- 
      ...ich hab' noch einen Koffer in Berlin...