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/