[outcome] Outcome v2 has reached stability, WG21 paper will be P0762R0
For boost-dev's information:
https://www.reddit.com/r/cpp/comments/6qo1m3/outcome_v2_has_reached_stability_wg21_paper_will/?ref=share&ref_source=link
--- cut --
I am pleased to announce that Outcome v2, rewritten to fulfil the Boost
peer review feedback from May and only reaching feature completeness
three weeks ago, has been successfully deployed into two complex
libraries which were heavily using Outcome v1. Lots of bug fixes and
maturity has resulted, and if you were holding off on deploying Outcome
into your own code until now, now is the time!
The code itself is now ready for a second Boost peer review, it has all
the same testing that v1 had, and I am highly confident as to its
quality. What solely remains before Outcome v2 can reenter the Boost
peer review queue for a second review is the documentation which remains
parlous (and any help with it is greatly appreciated!), and the
"Boostification" cronjob script as the peer review wants a "pure Boost"
submission. I am also going to have to fix a number of bugs in
Standardese the documentation tool first, it currently segfaults when
fed the Outcome headers :). @foonathan's tool shows lots of promise, it
does far better with C++ 17 than doxygen, just need to shave off some
rough edges in the tool.
What comes before that though is writing a WG21 paper P0762R0
summarising the Boost peer review which led to the stripped down,
barebones v2 `result
On 07/31/2017 02:23 PM, Niall Douglas via Boost wrote:
[...] and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission.
Where would one find the script and the result of the boostified headers? What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
On 31/07/2017 15:04, Thomas Heller via Boost wrote:
On 07/31/2017 02:23 PM, Niall Douglas via Boost wrote:
[...] and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission.
Where would one find the script and the result of the boostified headers?
As the announcement said, the boostification script has not been implemented. Nor will it be until the documentation and tutorial are finished for obvious reasons. That's some months away yet, probably November or December, after the Meeting C++ conference and the Albuquerque WG21 meeting. The implementation code however is ready to go, and works very well with Boost code as it's exactly like a STL vocabulary type. If you can meet the steep compiler version requirements of course.
What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
Outcome runs on both Travis and Appveyor. Each cannot know if the other succeeded. So a cronjob which already exists scans nightly the CDash for Outcome, and figures out the last commit with all tests passing on all platforms. It then updates master branch to that commit, and publishes a tarball. That same cronjob will eventually also Boostify Outcome into the Boost.Outcome repo if and only if all tests pass i.e. master branch got updated. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/31/2017 05:01 PM, Niall Douglas via Boost wrote:
On 31/07/2017 15:04, Thomas Heller via Boost wrote:
On 07/31/2017 02:23 PM, Niall Douglas via Boost wrote:
[...] and the "Boostification" cronjob script as the peer review wants a "pure Boost" submission.
Where would one find the script and the result of the boostified headers?
As the announcement said, the boostification script has not been implemented.
D'oh ... missed that in the announcement... thanks for the clarification.
What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
Outcome runs on both Travis and Appveyor. Each cannot know if the other succeeded. So a cronjob which already exists scans nightly the CDash for Outcome, and figures out the last commit with all tests passing on all platforms. It then updates master branch to that commit, and publishes a tarball. That same cronjob will eventually also Boostify Outcome into the Boost.Outcome repo if and only if all tests pass i.e. master branch got updated.
While the two CI systems don't know of each other, you can actually get notified when a commit status update occurs. That would require some service to listen on those status updates and logic to determine if all builders passed (which is moot if you have testers not running on travis or appveyor). So I guess a cron job is the only alternative for the lack of proper CI support on this.
Niall
What's the rationale in having it run as a cronjob instead of having the CI do the boostification upon a successful build?
Outcome runs on both Travis and Appveyor. Each cannot know if the other succeeded. So a cronjob which already exists scans nightly the CDash for Outcome, and figures out the last commit with all tests passing on all platforms. It then updates master branch to that commit, and publishes a tarball. That same cronjob will eventually also Boostify Outcome into the Boost.Outcome repo if and only if all tests pass i.e. master branch got updated.
While the two CI systems don't know of each other, you can actually get notified when a commit status update occurs. That would require some service to listen on those status updates and logic to determine if all builders passed (which is moot if you have testers not running on travis or appveyor). So I guess a cron job is the only alternative for the lack of proper CI support on this.
Oh for sure. But that would be more work for not actually a huge gain. Having to wait till midnight GMT for update to known-working-on-all-platforms is okay for 99% of end users. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
participants (2)
-
Niall Douglas -
Thomas Heller