Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-19 22:00:12

> In the event the library is accepted, what will the contents of the
> repository boostorg/outcome be, and what will end up in the Boost
> release under libs/outcome?

That depends on what conditions the review manager places on acceptance,
if acceptance is recommended.

> Stated differently, is the entire ned14/boost.outcome repo being
> submitted as-is, or are some parts of it not part of the submission?

I am submitting it as-is in its present form. Reviewers may wish to
impose conditions regarding its boostorg form on acceptance.

> Furthermore, are the two Git submodules, doc/html and
> include/boost/outcome/boost-lite part of the submission and if so, in
> what capacity, that is, are they expected to remain Git submodules in
> boostorg/outcome, or are they expected to be copied there from some
> fixed revision?

The doc/html subrepo is simply the gh-pages branch used to deliver
Github Pages for the docs. Almost every recent Boost library submitted
does the same. If accepted, I'd do exactly whatever Boost.Hana did to
get its doxygen docs into boost.org.

As I've mentioned before, during build we assemble a single file include
of all the dependencies, including those parts of boost-lite needed.
There is therefore no strict need to ship boost-lite in any boostorg
repo, which is good as I believe boostorg currently doesn't support
project level subrepos.

But if that weren't acceptable, we could figure something out. To be
honest, I don't think it hugely important how we get Outcome into
boostorg, if accepted we'll figure out some solution which the build,
test and release managers are happy with and go with that.

Personally speaking, and reviewers can disagree if they want, what
matters is does the submitted library work well with Boost? I believe
the answer is that no collision, conflict nor bad interaction can happen
between any Boost code and any Outcome code. It therefore works well
with Boost.

Again, as I mentioned before, there is precedent here. When Hana was
submitted it didn't even use the STL let alone Boost. It also used cmake
and had no Boost.Build. Outcome follows exactly the path set by Hana.

> As I already asked, will boostorg/outcome be the primary source
> repository for Boost.Outcome? If there is a PR submitted against
> boostorg/outcome, what steps will need to be performed in order for that
> PR to become integrated into the Outcome code base?

I'd prefer not a script generated boostorg/outcome repo, it makes
maintenance harder. But if reviews impose conditions which require a
script generated repo as they did back in the day with ASIO, then I'll
make it work.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/