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