To be honest, I don't think it hugely important how we get Outcome into boostorg,
An interesting position. I, however, in order to decide between Yes and No, need to know what, precisely, will happen on Yes.
Of course I could say Yes if you do such and so, otherwise No, but it's good to know how you see things and what's your intent.
My opinion there is that the documentation, code, design and implementation are what is being reviewed. Build stuff and test stuff and maintenance stuff are of course important, but that's *process* stuff, it's secondary in importance relatively speaking. I mean, basically build, test and maintenance stuff is on me to get right, else I will spend enormous amount of my very limited free time on it. And I am highly unlikely to choose that situation. It is possible that the review places such onerous conditions on admission that I cannot see a path to take this codebase into Boost without completely rewriting it from scratch. I hope not, that would be a big ask.
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.
I'm not sure I understand. If you prefer not a script-generated boostorg/outcome repo, what do you prefer?
There's script generated within my build system. That's okay, it's already doing that, indeed that's going to get much worse with issue #25. Then there's script generated whereby a new git repo is one-way synthesised by cron script from another git repo (like ASIO). I'd prefer not to have to do this. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/