Subject: Re: [boost] [cmake] Pull request announcement
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-09-16 20:53:07
On 9/16/18 11:30 AM, Rene Rivera via Boost wrote:
> On Sun, Sep 16, 2018 at 1:20 PM Niall Douglas via Boost <
> boost_at_[hidden]> wrote:
>>> Instead of reposting pros/cons here again to make it into yet another
>>> forgotten post,
>>> those who care and need it should create a table on wiki with clear
>>> structured comparison.
>> It seems to me that the putative review manager (Robert) should [...]
>> make that table summarising
>> their different approaches.
> That's not normally the job of a review manager.
This is true.
> It's usually on the
> authors of the solution(s) to make relevant comparisons to other solutions
> both in features and performance.
So the CMake "review" is going to be somewhat different than traditional
a) we haven't reviewed tools. They were submitted and just accepted by
... I'm not sure whom. My motivation for promoting the idea of a review
is to diminish the chances of me getting stuck with something that I
don't like or is not useful to me. I also strongly believe in the value
of the boost review process, in spite of the fact that it's often
tedious, frustrating and never produces the exact result I want.
b) we haven't solicited new software components in any manner official
c) the author has an idea he wants boost to accept. The defines the
scope, the interface and implementation and submits if for acceptance or
rejection. If accepted, it becomes the defacto standard for that
functionality and it effectively shuts down alternative future
proposals. All in all this hasn't been a bad thing as it helps users
with the selection of the component. But I don't see this working well
in this case as I want everyone who want's to take a crack at this to
take a shot. And I want them to know that if they do the work in the
specified time frame, their work will be considered even though it can't
be guaranteed to be accepted.
d) often times libraries have been rejected because reviewers felt that
the scope of the library was ill-chosen. This was OK as the library
author got to propose what he wanted to. But now we're soliciting
proposals, so it's unfair not to specify what we're asking for - that is
Since previous discussions have demonstrated (to me at least) that there
is currently no well defined consensus as to what CMake should do in the
context of boost, I've proposed that this be nailed down first.
So here is what I propose:
a) I will review the history of the topic, including previous proposals
and get up to speed on the lastest facilities that CMake provides and
post a document: "Solicitation for proposals to add CMake support to
Boost" (or something like that - let the bike shedding begin!). I will
try to post this by 1 October 2018. This document will contain:
A list of functions that a CMake implementation is expected to perform.
These might include some of the following and perhaps other stuff.
1) Help users import Boost Libraries in to their projects
2) Help users test a subset of Boost libraries on their own machine
3) Help library authors run tests of their libaries during development
and post the results to a common area.
4) Help authors build IDE for their libraries to aid in development
5) Help everyone keep track of and accommodate source code and library
6) Other stuff that hasn't occurred to me yet.
A list of requirements that the submission should fulfill: License,
Documentation, quality of implementation, platform coverage, commitment
to implementation and maintenance for one year etc....
b) this "solicitation" will be subjected to comment and review by
members of this list for up to 30 days. At the end of this period, I'll
consolidate all this into a quasi official "Solicitation". If there
isn't sufficient consensus reached to create such a "Solicitation", The
process will end there.
c) On or about 1 November 2018, this "Solicitation" will be posted on
this list and the r/cpp forum on reddit. Authors will submit their
proposals "unopened" to me until 1 February 2019.
d) On or about 1 February 2019, Proposals will "unsealed" by me and I
will inspect them to verify that they meet the stated minimum
requirements such as documentation, tests etc. Any ones that fail this
pre-review will be rejected with thanks and a polite note written by me.
e) Any proposals still remaining will be posted along any explanatory
notes that I have on them. It is quite possible that no proposals will
remain at this point and process can then end without more discussion.
f) After a two week review period, I'll decide whether or not the
proposal is rejected or accepted and under what conditions.
Note that in the above I'm used the first person I rather than review
manager. This is just a convenience to make it easier to explain how
the process is expected to work. If there is a consensus that someone
else should do this, I'll be happy to support any other selection.
Interested parties should feel free to nominate themselves for this job.
So far, the Bored of Directors has been silent on the whole issue since
the initial proclamation a year ago. I don't think this is necessarily
a bad thing - if only to see what was going to happen. But now I think
it's time for them to decide a couple of things and make a couple of
a) that they endorse the process and designate the review manager (me or
b) consider offering a monetary "prize" for submission and
implementation of a winning proposal. I would expect such a prize to be
in the neighbor of 5000-15000 US$. Funds might come from any where and
the BOD would make some effort to gain sponsors for such a project.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk