Dear Ron, Louis, and Boost developers, The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support. I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library. Thank you again, Louis, for your work on Hana and for contributing it to Boost. I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful. I trust, but do not mandate before Hana is officially accepted into Boost, that: 1. All GitHub issues pertaining to implementation and documentation that were opened by Louis in response to review feedback (or by others, such as Vincente, that were approved by Louis) will be addressed eventually (as long as they remain relevant). I personally would ask for, but do not require for Hana's acceptance, that: 1. That Hana's non-reference documentation live outside of the source code. The presentation of Hana's documentation is great; it looks modern, is easy to browse. I am not a fan of the prose living inside hana.hpp though (API reference documentation is the only exception). 2. Louis to investigate further the possibility of a Hana core library if such can be achieved with zero overhead (instead of focusing that effort onto a separate library that provides only a subset of Hana's functionality). On the note of Hana's current support in existing C++ implementations: - While Hana is wholly only supported by clang at present, gcc is not far behind. Given the trend of language conformance, it is reasonable to expect Hana will be entirely supported in a future gcc release. - Hana targets the C++ standard (i.e. This isn't a case of targeting any compiler-vendor specific extensions) and any highly-contentious C++ language features within (e.g. This isn't something like a pre-C++11 library that uses 'export' that only builds with an EDG compiler). - The community now has expressed sufficient interest in both kinds of libraries being part of Boost: Highly portable libraries that target implementation-specific features, and maintain compatibility with even legacy compilers; standard conforming, modern, libraries that are free of the maintenance debt of ancient compiler support. - We need more libraries taking advantage of C++14 language features to drive vendor conformance. A standard may only be as potent as the C++ implementations that support support it, but when one (such as clang does) does, others will be more driven to follow suit when real (and highly desired) projects take advantage of it. My thanks to everyone that participated in Hana's review with a review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel, Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul, Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug reports. Best, Glen
On July 7, 2015 1:42:42 AM EDT, Glen Fernandes
I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library.
Thanks, Louis, for your efforts and for submitting a great library. Congratulations. Thanks, Glen, for your management of this review, including a rapid conclusion. ___ Rob (Sent from my portable computation engine)
On 7 Jul 2015 at 4:57, Rob Stewart wrote:
I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library.
Thanks, Louis, for your efforts and for submitting a great library. Congratulations.
Thanks, Glen, for your management of this review, including a rapid conclusion.
Thanks are also due to the Steering Committee for funding an extension to Louis' Google Summer of Code last year. I am sure Louis won't mind me saying that he spoke of how useful that extension was in his report to Google. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On Mon, Jul 6, 2015 at 10:42 PM, Glen Fernandes
The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support.
I submit that Hana be accepted into Boost. I want to congratulate Louis:
Congratulations Louis! And thanks to Glen for managing the review. --Lorenzo
Glen Fernandes
Dear Ron, Louis, and Boost developers,
The review period for Hana has concluded. 18 reviews were submitted: - 17 votes for acceptance. (1 of these was conditional upon Hana wholly supporting a second C++ implementation however). - 1 vote for rejection; for lack of compiler support.
I submit that Hana be accepted into Boost. I want to congratulate Louis: the Boost community wants Hana to become an official Boost library. Thank you again, Louis, for your work on Hana and for contributing it to Boost.
Thanks a lot to you for managing the review. I'd also like to thank everyone who participated in the review, and everyone who was involved with Hana since its inception. I think this is a big step for C++ metaprogramming, and I also think this is a nice step for the C++ language as a whole. Indeed, if some people start using this library, compiler vendors will _have_ to support C++14 properly, which will contribute to pushing the language forward. I also hope some techniques or ideas found in this library can find their way into the standard library.
I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful.
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
I trust, but do not mandate before Hana is officially accepted into Boost, that: 1. All GitHub issues pertaining to implementation and documentation that were opened by Louis in response to review feedback (or by others, such as Vincente, that were approved by Louis) will be addressed eventually (as long as they remain relevant).
Of course, this is a long shot, but I will work towards that goal. Also, I'd like to invite anyone willing to help to join this effort.
I personally would ask for, but do not require for Hana's acceptance, that: 1. That Hana's non-reference documentation live outside of the source code. The presentation of Hana's documentation is great; it looks modern, is easy to browse. I am not a fan of the prose living inside hana.hpp though (API reference documentation is the only exception).
I've been thinking about this, too. I'll put this in an external markdown file. See this issue [1].
2. Louis to investigate further the possibility of a Hana core library if such can be achieved with zero overhead (instead of focusing that effort onto a separate library that provides only a subset of Hana's functionality).
I'm currently working on a rather large patch which modularizes Hana. Basically, the goal is to have boost/ hana/ tuple.hpp -> only the tuple implementation xxx.hpp -> only the xxx algorithm concept/ XXX.hpp -> stuff related to the XXX concept What this would mean is that you can include only hana/tuple.hpp and get a lightweight and very efficient tuple implementation, and then include only the algorithms you need. Right now, the only choice is to include all the algorithms along with tuple.hpp, which I think was a design mistake. This patch will also make it much easier to fix other bugs, some of which I already have a fix for but can't apply it due to tight coupling.
On the note of Hana's current support in existing C++ implementations: - While Hana is wholly only supported by clang at present, gcc is not far behind. Given the trend of language conformance, it is reasonable to expect Hana will be entirely supported in a future gcc release.
Correct. We're not too far with GCC, especially if the library can spur interest and push more people to file bug reports.
[...]
My thanks to everyone that participated in Hana's review with a review (Edouard, John Fletcher, John Bytheway, Niall, Krzysztof, Manuel, Roland, Christophe, David Stone, David Sankel, Lorenzo, John, Paul, Zach, Kohei, Charley, Vincente, Abel) as well as discussion and bug reports.
Best, Glen
Regards, Louis [1]: https://github.com/ldionne/hana/issues/161
Louis Dionne
Glen Fernandes
writes: [...]
I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful.
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
Oh yes, I forgot to ask: Does being included in a Boost release require the library's API to be stable? Is it possible to put Hana in a release along with a note saying "still experimental" or something like this? From the library's point of view, being able to reach more users is a huge help because of bug reports and improvements that can follow. If this is not acceptable, I'll skip one or two official releases and wait until all or most of the non-backwards compatible changes triggered by the review are applied.
[...]
Regards, Louis
On 7/7/2015 2:24 PM, Louis Dionne wrote:
Louis Dionne
writes: Glen Fernandes
writes: [...]
I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful.
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
Oh yes, I forgot to ask: Does being included in a Boost release require the library's API to be stable? Is it possible to put Hana in a release along with a note saying "still experimental" or something like this? From the library's point of view, being able to reach more users is a huge help because of bug reports and improvements that can follow. If this is not acceptable, I'll skip one or two official releases and wait until all or most of the non-backwards compatible changes triggered by the review are applied.
What you are generally talking about is having some interface that may change in the future, or even in the very near future. While this is generally discouraged in good software I for one have never felt it necessary that some public interface detail never ever change, as long as the documentation explicitly tells the user that the change has been made. But I think what you are specifically talking about, which is that you will be making changes based on the review but you would like to release Hana as part of Boost before you make those changes, is not a good idea as far as Boost is concerned. Surely end-users can wait for Hana to be officially part of a Boost release until you have made the changes necessary and the regression tests show that your changes are passing its tests. In the meantime, simply by having Hana being part of the modular Boost tree, you will almost certainly get users interested in C++14 metaprogramming trying it out.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Louis Dionne Sent: 07 July 2015 19:25 To: boost@lists.boost.org Subject: Re: [boost] Boost.Hana
Louis Dionne
writes: Glen Fernandes
writes: [...]
I propose we require, prior to Hana's inclusion in a Boost release, only that: 1. Hana's unit tests to be integrated into Boost's regression tests. If this requires maintaining both CMakeLists.txt and .b2 files, it is still worth it. I am willing to assist with this effort (and the invitation extends to anyone in the community to also contribute to the task). For release managers, potential Hana contributors, or just the general developer community in Boost, to see Hana's test cases in http://boost.org/development/tests/master/developer/summary.html will be useful.
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
Oh yes, I forgot to ask: Does being included in a Boost release require the library's API to be stable? Is it possible to put Hana in a release along with a note saying "still experimental" or something
like
this? From the library's point of view, being able to reach more users is a huge help because of bug reports and improvements that can follow. If this is not acceptable, I'll skip one or two official releases and wait until all or most of the non-backwards compatible changes triggered by the review are applied.
IMO Anything in develop branch will be viewed by users as somewhat experimental, especially by something cutting-edge like Hana - and you'll get the benefits (and reports of trouble!) from the test machines. Bleeding-edge users will start to get feedback (perhaps bloody). Once it goes into master branch, if there are any 'breaking changes' that will cause the users grief, you need to use the 'what's new' release notes to raise a big red flag. You can also use this to give advance warning of changes that you will make in future releases. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Louis wrote:
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
If the test matrix can be updated from Travis, that works too. Ultimately all we need is: - Test cases results/failures per compiler all viewed from one location: the Boost regression test matrix display - Easy for anyone to add/run a new test case, or update/run an existing test (which you've already achieved).
Oh yes, I forgot to ask: Does being included in a Boost release require the library's API to be stable? Is it possible to put Hana in a release along with a note saying "still experimental" or something like this? From the library's point of view, being able to reach more users is a huge help because of bug reports and improvements that can follow. If this is not acceptable, I'll skip one or two official releases and wait until all or most of the non-backwards compatible changes triggered by the review are applied.
(Paul and Edward gave you good answers). Stable is a good word to describe it. It is up to you as the library author, but interface-breaking changes are not forbidden nor unheard of in Boost (as you've seen). You'll want to use your best judgement depending on what you think is best for Hana, and for users of Hana. [You might even change your mind about the former, depending on the latter: Despite labeling it as experimental, if enthusiastic Hana users start using it in production code, you might be tempted to handle major changes differently]. As for the boring next steps (getting into github.com/boostorg, updating the sub-module in /libs, and the Jamfile.v2 for tests) we can talk off the mailing list, whenever you're ready. (Or you might already know the process for all of that anyway). Best, Glen
Glen Fernandes
Louis wrote:
Agreed. When you say "integrated into Boost's regression tests", does this mean it would be OK if the test matrix could be updated from Travis-ci? If that was sufficient and possible with Travis, that would be the best way by far because these tests are run on each push. Otherwise, I'll make the tests usable from Boost.Build.
If the test matrix can be updated from Travis, that works too. [...]
Awesome. I will look at how this can be achieved with the current setup.
[...]
Stable is a good word to describe it. It is up to you as the library author, but interface-breaking changes are not forbidden nor unheard of in Boost (as you've seen). You'll want to use your best judgement depending on what you think is best for Hana, and for users of Hana. [You might even change your mind about the former, depending on the latter: Despite labeling it as experimental, if enthusiastic Hana users start using it in production code, you might be tempted to handle major changes differently].
I think I'll wait for 1.60 or so, then. There are a couple of important improvements that must get in before Hana is ready to be used in production code.
As for the boring next steps (getting into github.com/boostorg, updating the sub-module in /libs, and the Jamfile.v2 for tests) we can talk off the mailing list, whenever you're ready. (Or you might already know the process for all of that anyway).
Ok; I'll contact you privately when I'm ready for the next steps. Thanks, Louis
participants (7)
-
Edward Diener -
Glen Fernandes -
Lorenzo Caminiti -
Louis Dionne -
Niall Douglas -
Paul A. Bristow -
Rob Stewart