Library devs only: Boost v2.x distro design questions

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Library devs only: Boost v2.x distro design questions

Boost - Dev mailing list
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?

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?

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?

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

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)

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

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

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.

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

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

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 could go on, but let's stop there for now.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
And answering my own questionnaire ...

> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?

I am willing.

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

I would like a new separate Boost v2.x distro in addition to the v1.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?

I would keep different editions of Outcome in each, with different
configuration and defaults.

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

C++ 17, as that is where surveys say the userbase is moving to from C++ 11.

> 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'd prefer the inline namespace.

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

Probably cmake. I could be convinced with Build2, if it spat out
exported targets for cmake consumption.

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

Yes I think they should. As a header only library, Outcome is very easy
to integrate into any package manager, indeed it's already built-in to
godbolt.

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

Initially speaking, I think the rolling release suits best at the
beginning. As things stabilise and mature, then proper releases seem
appropriate.

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

Definitely local HTML server. Static HTML is so 1990s.

> 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

I think it should be standard choice. I know that requires a Python
installation on people's machines to build, read docs, or indeed do much
at all, but I think devs should get over it.

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

In my case, I have no hard dependencies on Boost at all. Though I'd like
Boost.Config and Boost.System ported over if possible. And maybe
Boost.Exception.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Oct 24, 2018 at 2:12 PM Niall Douglas via Boost <
[hidden email]> 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've already done it.

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

One.

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

Only one that works on whatever that is script generated from an entirely
separate github repo outside of Boost.


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

C++11 as that's where the user base is at 66% of users.

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

You forgot to also ask about macros.

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

Irrelevant.


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

You should watch <https://www.youtube.com/watch?v=sBP17HQAQjk>.


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

This has been asked before and the answer has been to keep releases.

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

NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x?


I wrote most of those Python scripts so I'm fine with it.


> For example, Python to run
> a local HTML server to serve documentation locally,


Different way to ask the previous question..
NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


> or Python to build a
> release etc
>

We already use Python for releases etc. works fine and reliably.

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

The build system and Predef.

--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
AMDG

On 10/24/2018 01: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?
>

No.

> <snip questions rendered irrelevant by Q0>
In Christ,
Steven Watanabe

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2018-10-24 03: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'm not sure whether I'm thinking too much about implementation details
here, but I expect this to imply a repo fork (or at least a separate
branch) of my libraries, so I can strip off support for
no-longer-supported language variants. And I assume that by "distro" you
mean a set of releases built from those forks, rather than the current
set of repos. Correct ?

My answer is "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?

By all means, a separate one ! (Isn't the whole point to strip off
legacy support ?)

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

That depends on the library and the existing amount of legacy support.
In either case I'd keep support for "Boost 1", at least until I get a
sense that all users of the library have moved to the new "Boost 2" version.

>   Also, would the version in
> v1.x be hard forked from any v2.x edition i.e. the v1.x edition would
> get orphaned?

I'm not sure how to interpret the question. It's possible I'd share
bugfixes among both versions, but otherwise they would evolve more or
less independently. (Very likely the "Boost 1" version would move into a
strict "maintenance mode", without any actual development, as that would
presumably move to "Boost 2" only.)

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

This question implies to many assumptions for me to answer in simple
terms, so let me step back a little:

The only way forward, *in particular* if we bootstrap a "Boost 2", would
be a fully modular set of libraries.
The choice of build system will be up to individual library projects, as
would the choice of minimal C++ standard.
Further, a particular set of flags used to produce binary releases
(including what C++ standard feature is used) isn't particularly
important, at least as far as the definition of the project itself is
concerned. It may however be restricted by the set of standards that are
actually supported.

> 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 both Boost versions to coexist in a single translation
unit. Any versioned namespace seems fine, as I can alias it in user code.

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

None. Boost should be fully modular, and if we can't manage to do that
for "Boost 1", we should at least start "Boost 2" with full modularity
right from the start, and build-level requirements should be
communicated in a build-system-agnostic way.

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

Such integration is a nice-to-have feature, but shouldn't be handled
centrally. (Modularity & autonomy !)

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

official releases in the long term. (Obviously, to get there and to
establish a stable cadence will take time)

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

As previously, that shouldn't be a centrally managed concern.
Documentation should be up to individual library projects.

> Q9: What are your feelings towards the use of Python to script
> infrastructure and tooling in any Boost v2.x?

Python ! :-)
>   For example, Python to run
> a local HTML server to serve documentation locally, or Python to build a
> release etc

These are implementation details we shouldn't be concerned with.
*Please* learn from past errors and don't reinvent tools (and
infrastructure) unless you absolutely have to. For now, github and its
tools and support services are totally sufficient. And even if we have
to move, let's not start a Big Unified Discussion On Tooling Again !!

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

That's an interesting question. In the projects I'm currently involved
in (Boost.Python, Boost.GIL, Boost.uBLAS) we are trying to (slowly)
replace dependency on core components by C++11 equivalents (from
type_traits over shared_ptr etc.), and I'm not sure what dependencies
will remain once that endeavor is finished.

> I could go on, but let's stop there for now.

Stefan

--

       ...ich hab' noch einen Koffer in Berlin...
     


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/24/18 12:12 PM, Niall Douglas via Boost wrote:

I think this question is ill-formed.  It presumes that someone (us) can
determine what other people are going to do.  No one has the authority
or influence to do that.

But what can we do then.  We can provide support for those who want to
restrict their choices of Boost libraries according to their own
criteria.  That is:

a) given information about a library, e.g. which level of C++ is
required, is it actively maintained and supported, etc. etc.

b) show me a list of elgible libraries.

c) and tell me if any on that list are dependent upon on non elgible
libraries.

d) decide which subset of Boost I want to use.

e) download and build that subset.  Presumably this subset will be
compatible with each other. Let's call that a "closed compatibility
subset" - or for brevity "closed subset".

Now I can download, build any closed subset that captures the
requirements that I have set.  If I'm lazy - and I am - I could use
someone elses prepared list - C++17 compatible libraries.  Or C++03
libraries presumable a larger set. If I'm not lazy I might make my own
closes subset - those libraries which don't required RTTI. or ...


In short, rather than having the Boost organization try to make these
subsets for me through some sort of review process, just help me make my
own subset.

Now implement "modular" boost and we're done.  Libraries no longer in
use are siting out there somewhere - but who cares - they're not
polluting anyone's universe.  The whole problem just becomes a non
problem.  No committees, no discussion, no pain, no deprecation, no
discussions about replication, no boost policy regarding library
support, no discussions about what boost policy regarding library
support. no wasted time - all for the cost of a little bit of "wasted"
disk space.  Wouldn't that be heaven?

Now the only thing we need to do to get all of these benefit is to make
it easier to use a subset of the whole of boost.  That is Boost
Modularization. In order to do this we need:

a) Consensus that this is necessary and valuable.

b) More detail on what has to be done to achieve this.  A

c) Some implementations.

Amazingly, slow progress is being made on all three fronts.  I've very
hopeful for the future!

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/24/2018 3: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 have less than zero interest in forcing Boost libraries to adopt some
arbitrary C++ standard.

I can understand only one thing, as evidenced by my cxxd library which
nobody liked as a solution, that it would be helpful for a library which
uses a Boost library rather than the C++11 equivalent library to use the
C++11 equivalent library instead and therefore drop support for C++03.
Beyond that forcing some library to use some C++11 on up construct, just
to adopt some arbitrary C++ standard, is lunacy.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Oct 24, 2018 at 12:13 PM Niall Douglas via Boost
<[hidden email]> wrote:
> Q0: Are you willing to do the work to adapt your library for any Boost
> v2.x distro if it were to happen?

I will literally do anything if it means another GitHub star.

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 10/24/2018 5:14 PM, Vinnie Falco via Boost wrote:
> On Wed, Oct 24, 2018 at 12:13 PM Niall Douglas via Boost
> <[hidden email]> wrote:
>> Q0: Are you willing to do the work to adapt your library for any Boost
>> v2.x distro if it were to happen?
>
> I will literally do anything if it means another GitHub star.

Are you sure you are not secretly a chef and meant Michelin instead of
GitHub ?

>
> Regards


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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".

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/24/18 12: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?

any ?  hmmm - couldn't promise that.
>
> Q1: Would you prefer a new, separate Boost v2.x distro in parallel to
> the v1.x distro,

no

or to keep everything within one v1.x distro?

Just cherry pick the boost libraries you want use in your v2.x fork. You
don't even have to aske me.
> Q2: Would you be intending to keep your library inside Boost v1.x,
yes
move
> it exclusively to Boost v2.x,
no
  or have it exist in both Boost v1.x and
> v2.x but with different defaults configured?
as I said, just create your own fork.  You can
a) post PRs to the "golden copy"
b) change whatever you want
c) Merge changes in the "golden copy" back into your fork before you
"release" or whenever convenient.

> Also, would the version in
> v1.x be hard forked from any v2.x edition i.e. the v1.x edition would
> get orphaned?
no - you or anyone else can fork from it for any desired reason.  The
golden copy in my case will always be compatible with all versions of
C++03 .. ?  Of course if you want to use it as part of an application
you'll have to compile your copy with the same compiler your application
is using.  You're totally free to do that and can expect it to work.

> Q3: What C++ standard should Boost v2.x's master build system be
> defaulted to? C++ 11, 14, 17 or 20?
whatever you want.  It's still a free country.

> 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 golden copy will use the current namespace.  If you wanted you could
probably wrap the headers to effectivly change them.  But if I were you
I wouldn't do that as it would entail nothing but grief.  Another thing
you could it is just global replace all the namespace names boost to
boostv2.  Remember (I believe) you'll always be able to merge the golden
copy back into your local one.

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

whatever works best for you.

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

again. whatever works best for you.  Were you to conjure up something of
value in boost v2 - and we ask you to do it - feel free to create a PR
so we can use it in the "golden copy"

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

again whatever works best for you.  feel free to experiment.

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

you could do that on v2 however you want.  This question is actually
interesting however.  Personally I've advocated that every library have
statically defined BoostBook or quickbook documentation and from that
generate on demand documentation in html, singlepage html, and PDF using
the boostbook system.  I've also argued that the static web pages built
either by hand or via the boostbook system should be part of the
library.  My main reasons are modularity and regularity as not all
documentation is made with boostbook.  This is historically a stick
subject and will continue to be.

> 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

oh - one more language to learn - just to release.  No thanks. I'm kind
of busy.

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

mpl, iterators, sprite, and likely a lot more.
>
>
> I could go on, but let's stop there for now.

You're welcome.

Robert Ramey
>
> Niall
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 10/24/18 6:31 PM, Robert Ramey via Boost wrote:

My real point here Nail is that you're conflating two separate issues.
Library development, design, and maintenance with library deployment.

You could relatively easily deploy a "closed" subset of boost which was
"cleaner" or simpler, or whatever just by selection.  It would achieve
everything you've wanted to achieve:

a) exclude libraries no longer maintained.
b) exclude libraries which are not compatible with newer libraries (I
don't think any of these exist)
c) exclude libraries which do not provide, in your humble opinion, any
useful functionality.

Think bigger.  You could create a special deployment of Boost for
students which would a closed subset which one could start to use much
faster than being confronted with the whole of boost and standard library.

Think bigger yet.  Create a deployment for beginners in C++.  Call it:
"Boost for Dummies"

This may sound funny, but I don't mean it to be.  I see the idea of
creating "curated" Boost/C++ deployment as being a really useful and
valuable idea which doesn't require that all the boost "cats" to be
harnessed to the "next big thing" which ain't going to happen.

This single most valuable step to this goal would be to cajole the
maintainers of the libraries to create documents in BoostBook if they
don't already.  I don't know how many are left.  But that "Might" and
the one's that aren't are likely so old you wouldn't want them in your
"Boost for Dummies" anyway.  Boost book can be rendered with great
flexibility and it would be possible to craft a beautiful publication
quality book that would be really useful to a lot of people.  I can see
it now:

C++/Boost for Dummies
by
Nial Douglas - Principle Architect of Boost.

So I think I see where you're trying to go with this.  And I see the
merit in it. But if you approached in the way I suggest, I think it
might be more likely to get you what you might be seeking.

Robert Ramey


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Wed, Oct 24, 2018, 22:12 Niall Douglas via Boost <[hidden email]>
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?
>

At most half of them.


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

One distro please.


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

I'll keep the remaining half of the libraries in both Boosts. The defaults
will be different. I'll keep maintaining all the libraries.


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

17 at least.


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

It should be namespace boost { inline namespace v2_VERSION { }} where
VERSION is the minor version of current release. Many people were
complaining that they have to use two different versions of Boost.
Different versions do not link well.


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

The most popular ones. Cmake leads right now.


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

I'd leave the packaging to the package manager authors. We have other
things to do, rather than supporting 5-37 different package managers.


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

Same as with Boost1


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

Don't care.


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
>

Python is a good language.


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

Asio, intrusive, container, program_options, spirit, predef... too many to
enumerate all of them.


I could go on, but let's stop there for now.
>

The idea of Boost2 is a good idea. But let's move evolutionary, rather than
revolutionary. Deprecate and remove the libraries, set cxxstd=14 by
default, mark outdated/unmaintained libraries with some mark in the docs,
add inline namespaces with version, add modules ts support... In a few
years we'll be able to change the major number to 2.

>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> On 24. Oct 2018, at 21:12, Niall Douglas via Boost <[hidden email]> wrote:
>
> Splitting this off from the other thread, can I get feedback from Boost
> library maintainers ONLY. Not users, not non-maintainers.

Since boost.histogram was accepted (conditionally)….

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

I didn't follow the discussion enough to understand the question.

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

There should be only one official version of the library, so Boost v2.x exclusive.

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

C++14.

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

inline namespace.

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

cmake.

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

Yes.

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

Rolling releases.

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

No preference.

> 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

Python is awesome and becoming the de-facto default scripting language. More Python please.

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

core, callable_traits, multiprecision

PS: Excellent comments by Vinnie and follow-up by Edward. Lol.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
> I think this question is ill-formed.  It presumes that someone (us) can
> determine what other people are going to do.  No one has the authority
> or influence to do that.

It's a question of there being a consensus, and if not, a sufficient
critical mass.

What I saw there before is the usual complaints as we've seen here for a
decade now, the usual suggestions for solving it, and the usual lack of
anybody actually doing anything. Which is just pointless noise.

So I made that questionnaire to see who would publicly go on record with
where they are currently at. There is obviously no consensus, though I
note with excitement how many fewer naysayers to real change there are
compared with even three years ago. So clearly things are shifting, and
I note a number of people whose opinion has transformed radically from
where they were only recently.

That means that if somebody did roll together a tighter, smaller, more
focused Boost 2.x distribution of the better quality libraries, it might
have legs. Up to you Boost!

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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
<[hidden email]> wrote:
>
> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost [mailto:[hidden email]] On Behalf Of Niall Douglas via Boost
> Sent: 24 October 2018 20:13
> To: Boost Developers List
> Cc: Niall Douglas
> Subject: [boost] Library devs only: Boost v2.x distro design questions
>
> 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?

NO!

The work maintaining any separate distro is out of the question as far as I am concerned.

We have discussed this endlessly before.  Boost.Math is by far the largest library in Boost with the most tests.  It is written, for
history reasons, needing C++03 and this will probably continue.  C++03++ etc features are not used gratuitously, but anything that
is supported by the leading compilers is on the menu if there is a good reason. For math special functions and stats distributions,
new language features rarely off much benefit in performance, though some readability may be improved.  It is entirely header only,
so no linkable libraries must be built.

Boost.Math's organ grinder will very probably have a similar view ;-)

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

If people want to maintain the current mainly c++03-ish  state, they should freeze on a particular Boost release (and do their own
patching if a particular bug fix applies to them).

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

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

We should stick with the long established What You See Is What You Get  ( and by see I mean "consult the regression matrix to see
what a particular library and feature work OK").

And also the ultimate test SISAS (Suck It And See) still applies.
 
> 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)
>
> Q5: What master buildsystem should Boost v2.x use? Boost.Build, cmake,
> Build2, something else?

Boost.Build - have you looked at the Boost.Math jamfiles?
CMake can run b2 - but this is only really useful for test.

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

No release of Boost.Math has ever passed all tests of all functions with all compilers, and I believe that it never will.  
That doesn't mean this is not exceedingly useful and very, very widely used.

> Q8: Should Boost v2.x use a local HTML server to serve documentation,
> and the static HTML docs be dispensed with as a requirement?
>
> 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.

I don't speak Python, and my brain is full :-(.
 
> 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?

Sorry but this is a fundamentally flawed idea, applicable only to tiny (but often fiendishly difficult) libraries only. Boost covers
much more, and should continue to do so.

Paul

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
+44 (0) 1539 561830






_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost