Re: [boost] Boost Evolution

David, On 17/05/2016 20:27, David Sankel wrote:

On Tue, May 17, 2016 at 10:37 AM, Robert Ramey wrote:

...

Take a look at the CMake history. There was a huge effort undertaken from the top to switch to CMake for build / test. It was a failure because it tried to do it from the top down. I'm thinking that the promoters of this idea concluded that the problem wasn't ambitious enough and added deployment to the task and built rypll. This had as key collaborators our most capable and hard core developers - including David Abrahams and Eric Neibler. Huge amount of expended effort but not much came out of it.

This is a false account of what happened. CMake was dropped because the modularization to git was considered a worthwhile thing to do first. After the so-called top-down transition to git (which was good for C++, but bad for insiders), the steering committee somehow came to the conclusion that their job wasn't to steer. After last week's future of boost session (or lack-of rather), my understanding is that this is being revisited.

Could you clarify why you think your account is true, and Robert's is false? I don't know what's happening at C++ Now, but I don't think you regularly participate in this mailing list, whereas Robert does, so I'm surprised by the forceful statements that you make.

Boost cannot evolve the way it has in the past. When it was getting started, we didn't have over-representation of groups who benefit from the status-quo. We didn't have the idea of servicing the "Boost community" instead of the "C++ community". Either the steering committee will step up to protect the original vision of Boost, or the vision of Boost will change to serve the insiders. This means life or death for boost and, frankly, it's been dying over the past few years.

Just as reminder, the original vision of Boost can be found at http://boost.org, and it cannot be protected in its entirety for long - the C++ standard is not infinite, and the role of Boost as "existing practice" for standardization becomes less relevant as the standard becomes longer, while its role as collection of peer-reviewed production libraries will probably be more important. I don't know who are insiders that are getting served, and what benefits who gets, and what "C++ community" you have in mind, but anybody I discuss Boost with are mostly concerned about overuse of templates and meta-programming, along with the lack of any API or ABI stability. Serving those C++ users requires stability and solid engineering above all, and this is what is presently missing. -- Vladimir Prus http://vladimirprus.com