Re: [boost] [cmake] Pull request announcement

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.

Also true.

So the CMake "review" is going to be somewhat different than traditional 
reviews. Traditionally,

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 
or otherwise.

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 
the "scope".

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 
dependencies.
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 
announcements:

a) that they endorse the process and designate the review manager (me or 
someone else).

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.

Robert Ramey