[boost] A modest proposal for Boost evolution

Subject: [boost] A modest proposal for Boost evolution
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-07-19 18:53:46

I) Accept proposals for new boost tools into the review queue.  Such 
tools might be just Cmake templates or things like that.

Encourage members of the developer's list to submit proposals to support 
efforts by library developers to (for example):

a) CMake for building and testing libraries
b) Creation of Find(library) to help boost users who use CMake
c) Creation of CMakePackage(Library) (actually I don't know what this is 
but it has been mentioned.
d) Addition of continuation integration testing via appveyor, travis or 
whatever

Note that above ideas would be likely installed on a library by library 
basis.  Also note that above ideas not much dependent upon each other. 
There is not requirement that they be installed all at once.

Such proposals would be added to the "Boost proposal review queue" and 
be addressed via a similar procedure to that used to decide acceptance 
of proposed libraries.  Since most of these proposals take the form of 
"best", "suggested" or "required" practices they would take the form of 
explicit requirements and procedures described in a document in a common 
format.  This document would be posted as part of the Boost web page.

Obviously, such proposals would have to be specific enough for library 
developers to "paste in" or otherwise implement without a lot of 
investment of effort.

In the past, Naill posted his "best practices" and I've made my own 
personal recommendations on the boost library incubator pages, but these 
don't have any "official" acceptance.  The above would build consensus 
for what we might think of as boost best practices, boost requirements, 
or something like that.

II) Accept proposals for new boost tools.  These would be code.  There 
are already a few tools such as bcp, boost dependency analysis, 
library_test and perhaps others.  I propose that tool proposals be 
accepted and reviewed just as libraries are.  Examples of things I would 
like to see coming out of this might be:

a) better discussion and concensus on what "Dependency" means in the 
context of boost libraries and a tool which reflects that concensus.

e) Dashboard for test results from CI systems similar to or perhaps 
integrated into the current test matrix.  Actually, I would like to see 
this dashboard include tests run by users similar to the way that 
CTest/CDash is supposed to work.

f) Serious enhancements to existing tools.

Of course proposals for such tools would have to include (mostly) 
working code so that a proposal can be actually evaluated.

Note that the above focuses on evaluating specific proposals which are 
(more or less) ready to implement.  There's not much point in spending a 
lot of time discussing ideas which have yet to arrive to this stage of 
development

I had a lot to say about all this in my boost 2.0 presentation at CPPNow 
back in 2015.  Unfortunately, the presentation wasn't recorded but the 
slides are available at

http://rrsd.com/software_development/boost/C++Now2015/index.html

Robert Ramey