CMake for Boost initiative
36 views
Skip to first unread message
Robert Ramey
Nov 17, 2018, 12:25:22 PM11/17/18
to boost-s...@googlegroups.com, Ron Garcia
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.
Requirements and Scope
======================
Requirements
------------
Submissions will fulfill the applicable requirements of any boost
submission. This will include:
a) any necessary code.
b) specifications/requirements for things like directory structure
and contents.
b) A useful 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
-------------------------------
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
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.
Requirements and Scope
======================
Requirements
------------
Submissions will fulfill the applicable requirements of any boost
submission. This will include:
a) any necessary code.
b) specifications/requirements for things like directory structure
and contents.
b) A useful 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
-------------------------------
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
Nevin Liber
Nov 17, 2018, 2:21:41 PM11/17/18
to boost-s...@googlegroups.com
On Sat, Nov 17, 2018 at 11: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.
My questions are:
- Has the legal representation for Boost signed off on this? For instance: what happens if you can't raise the money? Is Boost on the hook for it? (Yes, I know that you want to write it so both you and Boost aren't liable, but I don't know if you can from a legal perspective, as IANAL.)
- What happens to the reputation of Boost if things go wrong (for instance, the review manager decides not to pay anyone the money)?
Nevin ":-)" Liber <mailto:ne...@eviloverlord.com> +1-847-691-1404
Jon Kalb
Nov 18, 2018, 4:01:50 PM11/18/18
to Robert Ramey, Ron Garcia, Boost Steering Committee
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?
———————————————
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-steerin...@googlegroups.com.
To post to this group, send email to boost-s...@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.
Reply all
Reply to author
Forward
0 new messages