Robert, Since you and I have discussed this a bit, you know that I support this in general, but I’ve several reservations about this writeup and urge you not to publish this as is.
I’ll make a few comments inline, but the big red flag is the offer of money. No. Just no. This opens several different cans of worms and can go wrong in so many ways. Adding money to a successful dynamic can have unexpected consequences, including some that we might not be able to recover from. Further, there is simply no reason to do it. As you’ve pointed out, the amount is insufficient to compensate for the effort involved and the appearance of “doing it for the money,” might even inhibit submissions from some individuals. All risks of it blowing up in our faces aside, it may be counterproductive and, although it may inspire trivial “why-not-I-might-get-lucky-and-win-some-money” submissions, it is certainly insufficient to motivate a submission capable of addressing the issue successfully. I’m not certain about what the details of the announcement should be, but I think there are some high-level issues that need to be addressed. Thanks. Jon > On Nov 17, 2018, at 9:25 AM, Robert Ramey <ra...@rrsd.com> wrote: > > I am now ready to announce Request for Proposals on boost developer's list > and concurrently on reddit/r/cpp. Before I do this I wanted to clarify some > issues and give you all one final opportunity to spit ball it. > > a) I've "re-purposed" the boost review process to permit the simultaneous > review of multiple submissions. I just want to make sure that there is a > consensus that this is OK so no one will complain after I take the leap to > open the argument "This is not the traditional review" or Ramey doesn't have > the authority to change boost procedures. or ... > > b) I'm including ron garcia (review wizard) on this email to make sure that > he also OK with this and to ask him to place these proposals in the queue for > review 15 February 2019. > > c) I've alluded to the award of a $5000 "prize" to the author of the selected > proposal upon integration into boost. David raised the question as to trying > to make this more flexible to make it more fair and encourage collaboration. > Do this would put the review manager (me - unless you've got some one > stupider than I am with a death wish to take on the task) in a sort of > impossible situation of trying to create "fairness" where none is possible. > One of the great virtues of the boost review process is that the reviewer > must actually make a thumbs up/down decision. The avoids the situation where > he gets sucked into the library design by accident. It forces all the > participants to get their licks in during the review - knowing that it will > be a definite discussion ending decision. It may not be perfect, it many not > be fair, but it's better than the alternative. It's like plastic surgery, > perfect always ends up worse than better. > > d) Right now the prize is unfunded. I've got 3 months to address this. It's > my plan to solicit sponsors for this award in the amount of $1000 each. I'll > be pitching: Boost, C++ alliance, Kitware and previous sponsors of C++Now. I > envision this working in the following manner. Payments are made to the Boost > account at the software conservancy to the amount of $6000. They take their > cut off the top and cut a check when requested for $5000. You'll have to > decide on the mechanics. > > Speak now, or forever hold your peace. > > Below is the document I plan on publishing. > > > Call for Submissions - CMake for Boost > ====================================== > > For some time, there has been interest on many users and developers of Boost > Libraries to make Boost easier to use with CMake. Discussions in the past > have not resulted in an implementation which has been widely accepted. Never > the less, hope springs eternal, and we intend to attempt this once again. It > seems that often there are difficulties before such projects even start in > that there are wide discrepancies as to what should be the goals and > expectations of Boost support of CMake. The aim of this document is to try to > build a consensus on this question before encouraging CMake developers and > experts to submit proposals for Boost support of CMake. This introduction is inadequate for several reasons, not just because “interest on many users” doesn’t make sense and “nevertheless" is one word. It is depressingly negative. “This is unlikely to succeed, but hope springs eternal that maybe this time we’ll get lucky and stumble onto a solution.” Most importantly, it doesn’t say what you are asking for. From what I recall of our discussion, you want to see designs for how to add CMake support to Boost, rather than complete implementations. That means that rather than a Call for Submissions it should be probably be a Call for Proposals. Spell out what you are calling for: We are calling for designs of solutions for adding CMake support to the Boost Libraries. These designs do not need to be complete implementations, but the Design Review Manager must be convinced that the implementation space has been explored thoroughly enough to be assured that a complete implementation is possible. The expectation is that the design submitter will be or recruit the lead developer and will “own” the implementation process including bug fixes and support extending into the future until at least a few library releases after the transition is complete. Although the Review Process will be similar in many ways to the Boost Library submission process it will differ in the ways listed below. > Requirements and Scope > ====================== > > Requirements > ------------ > > Submissions will fulfill the applicable requirements of any boost submission. Not if this is a design submission rather than a library submission. > This will include: The first thing that should be included should be an overview of the solution design listing features and advantages of the design approach and calling out trade-offs, non-features, risks, and costs (including development time). Then an implementation timeline documenting the work needed to be done including steps that are currently complete and steps that would need to be accomplished with an estimation of the effort and time involved for each of those. > > a) any necessary code. Not *any* necessary code. Unless we are asking for a complete implementation, then there will be necessary code that will not yet be written. > b) specifications/requirements for things like directory structure and > contents. > > b) A useful document. Do you mean an User Document? > Document should provide information, examples and templates so that a typical > C++ and CMake user should be able to do any of the following in a short time > - say 10 minutes. Document at a minimum should be viewable as html and/or > PDF file. After reading this document: > > 1) A library user should be able to incorporate a Boost Library into the > CMake script of an application which uses the Boost library in question. > > 2) A library user should be able to determine which additional Boost > Libraries he needs. > > 3) A library developer should find it simple to create the requisite CMake > files for his library. Thus the documentation should contain explanation and > perhaps other means such as examples and/or "templates" for required CMake > files. So a library author with no background in CMake should be able to add > CMake support to his library in a short time - on the order of an hour. > > c) test of CMake facilities supported by the CMake implementation. This will > include code, test of any features, capabilities that the submission > provides. Users expect that if they follow the instructions in the > documentation, they will get the promised results. A manner of > proving/demonstrating that this expection is realized this must be provided. > A likely response to this requirement would be a "test project" which can be > used to demonstrate that the submission actually works as expected. This > will be useful in the future for maintenance of the CMake Boost > implementation. It will permit the maintainer of the Boost.CMake facility to > work on and test their fixes and improvements without disrupting other > developers and users. It will also provide a template/example for Boost > Library developers endeavoring facilitate the usage of their libraries by > users of CMake. > > e) A commitment to support the submission, should it be accepted, for a > period of 5 years after integration into Boost. Such support would include > fixing bugs, updating documentation as necessary, and triaging of pull > requests. > > d) a Boost License > > Scope - Facilities and features > ------------------------------- > > CMake as it stands has lots of capabilities. But it has a fair amount of > complexity as well. Lots of things can be accomplished in multiple different > ways - each with subtly different results and effects. CMake for Boost will > likely consist of documentation, examples, CMake code, and other stuff to use > CMake to permit new features and facilities for users and developers of Boost > libraries. > > What follows is a list of facilities that Boost users and developers would > like to acquire with CMake for Boost. Those marked with * should be > considered hard requirements. That is, submissions which don't include this > feature can't be considered. Other items are interesting and would be > considered if included in a submission. > > *a) incorporating selected Boost Libraries into a user's application > > *b) incorporating selected Boost Libraries into a user's library > > c) building a boost library > > d) building a boost tool such as Boost.bcp, Boost.boostdep, etc. > > *e) In CMake, dependent libraries are specified as part of the library > CMakeLists.txt files. There several ways to do this and the subject is > pretty confusing to get right. Any submission documentation has to explain > to library developers how do this. > > *f) support of library modularity. This would mean: > *1) independence of things outside the library directory structure. To wit > - no presumption about any "super project". > *2) Building a library should not alter the source tree. > *3) no need for installing libraries not used by the library > *4) there should be no conflicts with other files. In particular, any > implementation should not hinder the usage of the boost.build. > > g) testing a boost library - if testing of Boost libraries is to be > supported, the following features should be considered. Those marked * > should be considered essential. > *1) execution tests - must pass / must fail > *2) compile only tests - must pass / must fail > *3) link only tests - must pass / must fail > 4) testing should be available to both library users and library developers > 5) should not depend upon tools other than a C++ and of course CMake > itself. > 6) test should have the option of posting the results to some public > "dashboard" which can be browsed by other users and library developers. > 7) option for recursive testing and/or building of libraries might be > nice. That is if library A uses library B and I test library A, this would > automatically test library B beforehand. > 8) Any build/test facilities should take into account the compiler > features as revealed by the tests for the boost/config library. This is > required to support the portability/universality which is one of the > hallmarks of the Boost Libraries. > > h) packaging - preparation of distributable, installable files for various > operating systems. That is, support for the CPack facility. > > i) There has been a lot interest and work in automatically determining > dependencies It's a much deeper subject than most people realize. Solving > this problem is not a requirement of the submission. However, submitters are > free to address this if they desire. > > j) Some have suggested a highly automated process including > downloading/updating, finding other components on other machines, etc. Overly > elaborate/opaque submissions will not be well received. > > Submission Rules and Procedures > ——————————————— Since I don’t know all the ins and outs of how a library review works, I’m not certain what is different here, but that is how I’d structure this section–by contrasting in with a library submission. It should probably also contain an overview of the complete process. What are highlights of what is different from a library submission review? This is a design rather than a library implementation Not all the necessary code has to be complete This is a competitive review rather than a review of a single library submission There is a specific time limit It is possible that the Review Manager will ask two or more submitters if a synthesized solution is possible. It is possible that instead of accepting a proposal, the Review Manager will opt to re-open the Call for Proposals. Are there other differences? > > a) This document constitutes a "Request for Submissions". It will be > announced on the boost announcements list, boost developer's list, > slack/boost, isocpp website and twitter account, reddit at r/cpp. Submissions > will be open to anyone. > > b) Submissions will be accepted at an email address to be specified. Received > submissions will receive a "prescreening" to determine that they meet the > requirements specified for such submissions at the top of this document. > Submitters will be notified of acceptance or rejection as soon as practicable. > > b) When authors are believe that their submissions are ready for review, they > shall notify the reviewer at ramey at rrsd dot com. The submissions will be > verified to meet the requirements and minimum scope as described above. > Authors will be advised of any deficiencies and given a chance to correct > them. When the review period starts, all information on submissions will be > posted on the Boost Developer's mailing list. > > c) The boost review process is described at www.boost.org . This instance > will deviate from that description in that we will review all submissions > simultaneously and select the one we would like to see incorporated into > boost. Other than it should be the same as the normal boost review process. > > c) The boost review process occurs on the boost developer's mailing list. > Authors of submissions should be subscribers to this list. Boost custom is > that subscribers use their real names. Its' been found that leads to more > productive discussion and effectively eliminates the participation of trolls. > Even so, discussions can get animated, but generally things are carried out > in a civilized level. However, if submitters desire to use an anonymous > handle on the mailing list they are free to do so. We understand that one > might want to do this for any number of personal reasons which are no one > else's business. > > d) Submissions will be closed on or about 15 February 2019. Boost formal > review will commence shortly there after. Depending on the number of > submissions received, the process may last as long as month. > > e) As per the boost formal review rules and customs, some time after the > review period terminates, the review manager will announce the review > results. This will likely contain some conditions regarding alterations > required in the submissions implementations. If the author find these too > onerous, and declines the opportunity to integrate his submission as an > official part of boost, the review manager may select an alternate > submission. It's also possible that the review manager may decide to accept > none of the submissions. > > f) when the submission is integrated into boost and is shown to fulfill the > conditions stipulated by the review manager. The author will receive a > "prize" of $5000 and a large but cheap medal on a ribbon hopefully to be > awarded at the next C++Now (Boost Con). As this is written, this prize is > subject to finding a funding source. It's understood that this stipend is in > no way compensation for all the work, aggravation of this task and commitment > to future support. But we hope that it will serve as a tangible token of our > gratitude for solving one of Boosts most pressing and difficult problems. > > Useful Resources > =============== > “Effective CMake" - https://www.youtube.com/watch?v=bsXLMQ6WgIk > https://gist.github.com/mbinna/c61dbb39bca0e4fb7d1f73b0d66a4fd1 > https://github.com/purpleKarrot/Boost.CMake > https://steveire.wordpress.com/2016/08/21/boost-dependencies-and-bcp/ > All boost discussions regarding CMake > > http://boost.2283326.n4.nabble.com/template/NamlServlet.jtp?macro=search_page&node=2600599&query=subject%3ACMake&days=0&sort=date > > Robert Ramey > > -- > The Boost Steering Committee webpage: > https://sites.google.com/a/boost.org/steering/ > --- You received this message because you are subscribed to the Google Groups > "Boost Steering Committee" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to boost-steering+unsubscr...@googlegroups.com. > To post to this group, send email to boost-steering@googlegroups.com. > Visit this group at https://groups.google.com/group/boost-steering. > To view this discussion on the web visit > https://groups.google.com/d/msgid/boost-steering/06ac0ec7-799c-afd1-222a-f5d69d42ad22%40rrsd.com. > For more options, visit https://groups.google.com/d/optout. -- The Boost Steering Committee webpage: https://sites.google.com/a/boost.org/steering/ --- You received this message because you are subscribed to the Google Groups "Boost Steering Committee" group. To unsubscribe from this group and stop receiving emails from it, send an email to boost-steering+unsubscr...@googlegroups.com. To post to this group, send email to boost-steering@googlegroups.com. Visit this group at https://groups.google.com/group/boost-steering. To view this discussion on the web visit https://groups.google.com/d/msgid/boost-steering/B6A190E2-A24E-411D-A3B6-5A91E514E8DC%40boost.org. For more options, visit https://groups.google.com/d/optout.
