Re: [boost] Library devs only: Boost v2.x distro design questions

Subject: Re: [boost] Library devs only: Boost v2.x distro design questions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2018-10-24 22:31:07

On 10/24/18 10:12 PM, Niall Douglas via Boost wrote:
> Splitting this off from the other thread, can I get feedback from Boost
> library maintainers ONLY. Not users, not non-maintainers.
> 
> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?

I don't know what you mean by "any v2.x distro", let alone by "adapting 
my library", so in this broad wording the answer is no.

> 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?

Again, it depends on what you mean by "v2.x distro".

> 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?

If there happens, let's say, a fork of Boost, I will definitely keep 
maintaining only one copy of each of my libraries.

If there is no fork and Boost simply increments its major version 
number, I will keep maintaining my libraries as before.

> Q3: What C++ standard should Boost v2.x's master build system be
> defaulted to? C++ 11, 14, 17 or 20?

There shouldn't be one imposed by Boost. If nothing is specified, let it 
be the compiler default. Otherwise, let the users (or packagers) decide 
what C++ version they want. Of course, Boost maintainers are free to 
decide which C++ versions they want to support.

> 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)

The implementation doesn't really matter, but the fork must not conflict 
with the current Boost. Otherwise it will be a major pain for the users.

But given that I don't intend to maintain two copies of my libraries, 
either the libraries will not be part of the fork, or someone else will 
have to perform the maintenance in the fork.

If there is no fork but just a new major release of Boost then I don't 
see the reason to change namespaces or macro names.

> Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,
> Build2, something else?

Something portable and capable enough to support Boost's needs. 
Popularity is a plus, but not a defining factor. Otherwise, I don't 
really care.

> Q6: Should Boost v2.x's libraries auto integrate individually into some
> package manager? If so, which ones do you intend to support?

No, none. Packaging should be done separately from the general 
maintenance, most likely by different people than maintainers. I'm 
willing to accept bug reports and patches from packagers about the code 
and build scripts, but not regarding packaging.

> 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.

I think, official releases are good for packagers and many users. Not 
everyone can or want to update every once in a while to a random 
revision from git.

Also, I don't believe there will ever be a point when 150+ libraries all 
pass 100% CI tests. Even with just one library I often get spurious 
failures.

Note that I don't mind releases of specific libraries on their own. I'm 
just saying that bundled Boost releases are still very much useful.

> Q8: Should Boost v2.x use a local HTML server to serve documentation,
> and the static HTML docs be dispensed with as a requirement?

Online documentation is a must, if that is what you mean. I don't really 
care how it is served, as long as the docs are reliably available.

> Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x? For example, Python to run
> a local HTML server to serve documentation locally, or Python to build a
> release etc

If this is a question about online server infrastructure then I don't 
care, as long as it works reliably and with acceptable performance.

If this is about my local system where I build stuff then no HTML 
servers or other fancy services please. When I build docs, I want to get 
a bunch of html files lying in some directory, that's it. How I view it 
is my business, and if I want to I will bring up an HTTP server myself.

> 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?

I use many Boost libraries, too many to list, some of them are in the 
standard library as well. Boost.Intrusive, Boost.Container, Boost.ASIO, 
Boost.Interprocess, Boost.Atomic, Boost.Spirit v2 to name a few off the 
top of my head.

I'm not sure what you mean by "porting".