Without trying to infer purpose, discuss validity or well-formedness
of your question,
I'm going to simply answer them as well as I can understand their plain text.
On Wed, 24 Oct 2018 at 21:12, Niall Douglas via Boost
Splitting this off from the other thread, can I get feedback from Boost library maintainers ONLY. Not users, not non-maintainers.
I'm member of Boost.GIL and Boost.Geometry. Lately, I've been less active for the latter though, but I'm interested in helping for any necessary modernization. Disclaimer: I speak for myself, and not for GIL or Geometry team.
Q0: Are you willing to do the work to adapt your library for any Boost v2.x distro if it were to happen?
Yes.
Q1: Would you prefer a new, separate Boost v2.x distro in parallel to the v1.x distro, or to keep everything within one v1.x distro?
New, in Boost master and develop, w/o looking back, but drawing fat thick line. I have no interest in maintaining anything pre-C++11 or pre-C++17, depending on the language version Boost decides to jump for. (I assume you mean distro as the "source distribution" as explained by eg. http://wiki.civiccommons.org/Releasing_Open_Source/)
Q2: Would you be intending to keep your library inside Boost v1.x, move it exclusively to Boost v2.x, or have it exist in both Boost v1.x and v2.x but with different defaults configured? Also, would the version in v1.x be hard forked from any v2.x edition i.e. the v1.x edition would get orphaned?
Move exclusively to Boost v2.x. Orphan Boost v1.x. (Unless the 24/7 time allowance becomes 48/7).
Q3: What C++ standard should Boost v2.x's master build system be defaulted to? C++ 11, 14, 17 or 20?
C++11 or C++17
Q4: Should Boost v2.x use a boost2 namespace, or namespace boost { inline namespace v2 { }}? (This affects whether Boost v2 and v1 editions of your library can be used within the same translation unit)
I don't expect or want to allow boost::v1::gil and boost::v2::gil be used in the same unit. Just namespace boost - fat thick line!
Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake, Build2, something else?
Boost.Build and CMake, both first class citizens. Hyper-ideally, Boost.Build port to Python and CMake.
Q6: Should Boost v2.x's libraries auto integrate individually into some package manager? If so, which ones do you intend to support?
No.
Q7: Should Boost v2.x have official release versions done by release managers, or should it be a rolling release of "whatever last passed the CI @ 100%"? Note that you can have this, and have official release versions of "especially known good" editions too.
The managers - the collection is too large to let it roll itself.
Q8: Should Boost v2.x use a local HTML server to serve documentation, and the static HTML docs be dispensed with as a requirement?
https://www.youtube.com/watch?v=umDr0mPuyQc
Q9: What are your feelings towards the use of Python to script infrastructure and tooling in any Boost v2.x?
I like Python a lot.
For example, Python to run a local HTML server to serve documentation locally,
https://www.youtube.com/watch?v=umDr0mPuyQc
or Python to build a release etc
Fine.
Q10: What parts of core Boost are you utterly dependent upon, and would absolutely need ported to any Boost v2.x as no STL alternatives exist?
libs/config libs/core libs/concept_check libs/test
I could go on, but let's stop there for now.
Please. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net