Re: [boost] Boost 2.0 ideas (was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's c

Subject: Re: [boost] Boost 2.0 ideas (was Re: Boost is supposed to serve *the entire C++ community; it isn't Boost's goal to serve Boost's c
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2016-05-20 11:45:32

On 20.05.2016 11:12, Robert Ramey wrote:
> On 5/20/16 5:25 AM, Niall Douglas wrote:
>
> Thanks for a good summary.
>
> I <sniped> the whole thing in the interest of brevity.  I don't intend
> to address the specifics of the proposal here.  It would be too long
> and way too off topic.  But I do have a couple of observations.
>
> a) It's breathtaking in it's scope.  You can't be accused of being
> timid. Feel free to take that as a compliment.
>
> b) There is no way Boost could get to this place starting from where
> we are now by means of evolution.  The gap is just too broad.  You'll
> have to think in terms of intelligent design rather than evolution. 
> This has been done before - after all boost itself was founded by a
> small group of people who decided to strike out on a whole new path.

This topic is coming up every couple of years, and sadly enough the
discussion eventually ends in exactly the same way, simply by running
out of steam.

I agree that the proposal as it is put forward is quite unrealistic. I
also think it's ill-conceived, precisely because it requires top-down
design rather than allowing for evolution. And at the scale of the
current Boost organization I think there just is no way to do top-down
design.

So my counter-proposal (which I have repeatedly voiced over past years)
would be to let Boost evolve into an *umbrella organization* with a
relatively high degree of autonomy for *member projects* to decide for
their own on things like what infrastructure tools to use (to build,
test, document, to track issues and feature requests, etc.), so long as
certain quality standards are maintained.

It is absurd how much ink is wasted on completely meaningless questions
such as where build system artifacts should be placed, as those have
absolutely no impact on end-users (and in fact don't even benefit boost
developers, as most of the time these discussions just fade away without
any conclusions, or even actions). So the only way to become more
efficient is to scale down the scope of such discussions to individual
projects and their communities.

At least I don't have any time to meaningfully participate in such
discussions, and so I put my focus on maintaining Boost.Python as
independently as possible, simply as a matter of efficiency.

        Stefan

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