On 16.06.2017 21:26, Robert Ramey via Boost wrote:
On 6/16/17 5:33 PM, Stefan Seefeld via Boost wrote:
[...]
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).
That's good to hear (even though it's not 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.
It's funny how most discussions here end up as tool discussions. ("When the only tool you have is a hammer, every problem looks like a nail.")
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.
Ditto.
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.
Let's be very conscious about the fact that the problem to solve is not the technical one (which is the easy part !), but the underlying systemic (social) one. And until that is being addressed, no tool will help us.
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.
Right. And even those requirements would have to be carefully to be minimally intrusive...
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
Yes ! (And for avoidance of doubt: "standards conforming" should exclusively be concerned about the outcome, not the way it is produced (which is an "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.
Agreed to all 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.
Thanks for following up. Yes, I think these are good goals. Is there no way we can build up momentum around these ideas to be able to move into that direction ? (And again, please let's not focus on any technical details how we achieve the above, but first and foremost agree where we want to go.) I'd be more than willing to help in any way I can. As Boost.Python maintainer I'm trying to go down that route anyhow. But I would appreciate company ! ;-)
Robert Ramey Stefan
-- ...ich hab' noch einen Koffer in Berlin...