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...