On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:
Hi David,
On 16.06.2017 19:44, David Sankel via Boost wrote: The problem isn't a technical one, it's systemic / organisational.
Agreed.
Boost has grown a lot, and neither its organization nor its infrastructure (of which the build system is just one part) doesn't scale well. So instead of substituting a tool, I would like to invite you to consider a few organizational changes.
Notably, I would like to see the long-stalled modularization process to be picked up again and be continued (and completed ?). Instead of managing all of Boost in terms of a single github super-repository, a single build system, a single issue tracker, a single website (etc., etc.), I'd like to see all of this to be broken out into separate projects, where most of the tool choices could be handled locally, i.e. per project The role of Boost as the organization would be that of a umbrella organization that defines certain guidelines, provides services (financial, legal, etc.), but otherwise tries hard to stay out of the way to accelerate rather than hinder development.
Looking at the current set of libraries, I can see a number that already are relatively independent, so the remaining change to complete the "modularization" is minor. (Take as an example Boost.Python, which few other Boost libraries depend on, and if so, only optionally so.) The rest could be incrementally separated, eventually leaving a single "Boost core" project, which everything else depends on.
Once there, you could rephrase your proposal for each individual library project to consider to switch. There wouldn't be a huge discussion flooding everyone's inbox, and consuming lots of time and energy from way too many people. Smaller groups of people would much quicker come to a conclusion, and the implementation of the change would be swift.
At least that's one dream I keep having...
This is the vision that I had when I made my proposal at C++Now titled Boost 2.0. It's also the vision that I had/have in mind when I create the Boost Library Incubator. I believe the two lines about fleshout the vision you've articulated so you've got two votes - (not that it's up for a vote). My presentation boost 2.0 was probably my least successful ever. I lost control of it as it veered into and argument about automatically generating dependencies. I was sott of struck by lightning. But still it articulated some ideas which have come to fruition such as the Boost Library Official Maintainer program and Boost Library Incubator. They haven't been the total success I would have hoped, but it does seem that we have less complaints about lack of library maintenance and we are reviewing more libraries which seem better prepared for review. Of course maybe it's confirmation bias. The last time this was discussed on the list, things circled down the drain of automatic dependencies. Let's not do this again. Let's just accept that somehow dependencies will be figured out, even if it has to be done by hand. The more interesting thing is the decoupling. Let each library decide which build, test, documentation, deployment, bug tracking system to use. The Boost Politburo would set requirements rather than design a specific system. Examples would be: a) every libary has to have documentation. Documentation has to be standards conforming. That is it would have to describe libraries in terms of valid expressions rather than implementation b) every library has to have a test suite c) every library has to have a single button download, build and test functionality. d) every library has to use a public version control system for it's source code e) every library has to use the Boost License f) every library has to fulfill a minimum set of directory structure requirements. f) Review managers cannot accept library into boost if it fails any of the above. Of course the Boost web page would have a portion which looks like the Boost library Incubator. So be it. Actually I've even considered just adding a page for each current boost library. The library dropdown would then specify accepted boost libraries, proposed boost libraries, etc. Building of all of boost would of just the sequence of "one button" download build and test for each library. I was going to put this in a separate post by you started down this path. Robert Ramey