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@lists.boost.org> 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