Boost, not LEWG

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

Boost, not LEWG

Boost - Dev mailing list
(A new subject, since the thread has evolved past the Text review result).

I spend part of my time in the C++ standards committee. I spend part
of my time in Boost.

I would prefer that my time spent in Boost, and that Boost itself, be
focused on its goals of serving the C++ community and Boost users
(existing ones, and growing to new ones).

If there is benefit of Boost to any other entity, be it the LEWG of
the committee, or some organization, that's great. i.e. When Boost is
adopted by some organization, or when Boost components go into the
standard, that's just a bonus.

But Boost itself shouldn't compromise on quality - in its review
process or what it ships in a Boost distribution,   to serve any of
those other interests.

Putting a bunch of experimental libraries into a Boost release just
because people have proposed them for standardization is not something
we should do.

If someone wants to, they can should just start their own project full
of libraries that have not undergone any kind of formal review, and
convince OS distributions to start including that as part of their
packages based on its own merits.

In case there was any misunderstanding on this point: Zach's goals of
standardization are his own, and in Boost we don't have to be
concerned with them. Because we're not changing the review process
because of them, and he's not asking us to.

Glen

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost <
[hidden email]> wrote:

> (A new subject, since the thread has evolved past the Text review result).
>
> Agree, thanks.


> I spend part of my time in the C++ standards committee. I spend part
> of my time in Boost.
>

Many of us do.


> If there is benefit of Boost to any other entity, be it the LEWG of
> the committee, or some organization, that's great. i.e. When Boost is
> adopted by some organization, or when Boost components go into the
> standard, that's just a bonus.
>

It used to not just be a bonus -- it's the prime reason Boost exists.  If
it no longer has that mission we should make that clearer.


> But Boost itself shouldn't compromise on quality - in its review
> process or what it ships in a Boost distribution,   to serve any of
> those other interests.
>

That is a decision for the Boost community to make, while there is still a
community.  If all C++ library development goes elsewhere then there won't
be much left.


> Putting a bunch of experimental libraries into a Boost release just
> because people have proposed them for standardization is not something
> we should do.
>

I disagree.  Consider how painful it is for a c++ programmer that wants to
contribute to the review proposed libraries for the C++ standard.  And by
that I mean, go and use the implementation.  In my case I was doing this
for c++20 -- it was super painful.  Aside from the time it took to go pull
from different places, compiler support and library quality/robustness was
all over the map.

In the past, when 90% of the things went thru Boost this meant downloading
Boost and going to town.   When TR1 came there was a special Boost package
for it.  The regression system would let you know where it worked and where
it didn't.

If someone wants to, they can should just start their own project full
> of libraries that have not undergone any kind of formal review, and
> convince OS distributions to start including that as part of their
> packages based on its own merits.
>

As you know well, the proposals for the standard are undergoing a formal
review, it's just not a Boost review.  And just so my intention is clear --
my goal is to increase the review of the proposals that make it into the
standard.  In my opinion the bar too the standard needs to be raised a
couple more levels.

After sleeping on it I like the idea more than ever -- so maybe I'll work
on it.  And if Boost doesn't want to distribute it then it's more of the
same mind share drain away from Boost.  I think it would be fine to ship
the proposed elements outside the main distro until it went thru a normal
review.  Ideally we'd get more authors to submit to a boost review and come
under the tent.  Maybe we could have some of the 'boostification' work done
by Summer of Code students.  Maybe this will led to more libraries like
asio that can ship standalone and in Boost as well.

In case there was any misunderstanding on this point: Zach's goals of
> standardization are his own, and in Boost we don't have to be
> concerned with them. Because we're not changing the review process
> because of them, and he's not asking us to.
>

Understood, but we should care about his effort to standardize.  Unicode is
hard, it's a mess in C++, and average programmers could use a Boost (sorry,
so sorry, not sorry :).  Ideally what Zach proposes will ship under the
Boost banner first.  Why?   So more than the maybe 20 people on the
committee will look at it before the ink is dried and it ships with
compilers.

Jeff

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sat, Jun 27, 2020 at 3:46 PM Jeff Garland via Boost
<[hidden email]> wrote:
>  Ideally what Zach proposes will ship under the
> Boost banner first.  Why?   So more than the maybe 20 people on the
> committee will look at it before the ink is dried and it ships with
> compilers.

It sounds like the committee's workflow is defective. If more people
should interact with the library before it goes into the standard,
here's a novel idea:

    Don't put it in the standard yet.

Why does Boost.Text have to go into the standard right away? Why can't
it enjoy life as its own non-std library for a few years, the way that
Asio did? Plenty of users and companies can enjoy the Unicode library
without it having to be in the std:: namespace.

Thanks

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sat, Jun 27, 2020 at 4:12 PM Vinnie Falco <[hidden email]> wrote:

> On Sat, Jun 27, 2020 at 3:46 PM Jeff Garland via Boost
> <[hidden email]> wrote:
> >  Ideally what Zach proposes will ship under the
> > Boost banner first.  Why?   So more than the maybe 20 people on the
> > committee will look at it before the ink is dried and it ships with
> > compilers.
>
> It sounds like the committee's workflow is defective. If more people
>

It has defects like any other process -- there is no perfect approach.  And
plenty of committee members agree (as you can see many on this list are
involved). In general, the committee responds only to people that bring
proposals -- that can be members of the committee or anyone in the
community.  If you write a paper and propose something the committee will
respond.

should interact with the library before it goes into the standard,
> here's a novel idea:
>
>     Don't put it in the standard yet.
>

That's correct, I really wish it were this easy.  So one of the 1st
questions a library will face is: is there an implementation?  And the
obligatory github repo is provided (do we go download and compile it - who
has the time?).   Next typical question:  Given the priorities of the
committee for the next release, do we want to spend time on this proposal?
I'm sure a few proposals fail this bar, but probably not nearly enough.
Part of the issue there being that c++ is forever behind in basic standard
library facilities compared to other languages - we still have technical
debt.

Of course that isn't it -- if your library proposal is small you have to
make it through a design study group, Library Evolution, and finally LWG.
It would be typically a ~2 year process.  You'd think that would afford
plenty of time for committee members to look at the details, but the world
is full of distractions.  If it's bigger....well read on...


> Why does Boost.Text have to go into the standard right away?


It doesn't, and I'd be personally surprised if it makes 23 (sorry Zach).


> Why can't
> it enjoy life as its own non-std library for a few years, the way that
> Asio did?


Many apologies to Chris K. on that from me (fun fact I was asio review
manager).  Without checking,  I think over a decade of his life has expired
working toward getting asio into the standard.  All of us owe Chris a huge
debt of gratitude for the endless hours he's spent.


> Plenty of users and companies can enjoy the Unicode library
> without it having to be in the std:: namespace.
>

While true, it's still very much surprising how many cannot. Being in std::
really is the ultimate c++ distro.

Jeff

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Jun 27, 2020 at 6:12 PM Vinnie Falco via Boost
<[hidden email]> wrote:

>
> On Sat, Jun 27, 2020 at 3:46 PM Jeff Garland via Boost
> <[hidden email]> wrote:
> >  Ideally what Zach proposes will ship under the
> > Boost banner first.  Why?   So more than the maybe 20 people on the
> > committee will look at it before the ink is dried and it ships with
> > compilers.
>
> It sounds like the committee's workflow is defective. If more people
> should interact with the library before it goes into the standard,
> here's a novel idea:
>
>     Don't put it in the standard yet.

That may be the right answer, but complaining about it won't fix it.
The reality is that people are going to put stuff into the standard
library.  The question then is not whether or not they should, but
what kinds of things go in.  The answer ought to be well-tested
existing practice.  Living in Boost for a while gives us the most
consistently good shot at that (you could just put stuff up on Github
and still get a lot of users, but that happens less often).  That's
why I think we should promote the use of Boost as a viable path to a
proposal.

> Why does Boost.Text have to go into the standard right away? Why can't
> it enjoy life as its own non-std library for a few years, the way that
> Asio did? Plenty of users and companies can enjoy the Unicode library
> without it having to be in the std:: namespace.

It doesn't need to, for most definitions of "need".  No one will die
if it doesn't.  No empires will fall.  However, C and C++ are the only
widely used production languages that do not have standard library
support for Unicode text processing.  I consider this embarrassing.
The existence of a Boost version makes things better, to be sure.
However, Boost is not ubiquitous, whereas the standard library is.

Zach

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
> On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost <
> [hidden email]> wrote:
>

> It used to not just be a bonus -- it's the prime reason Boost exists.  If
> it no longer has that mission we should make that clearer.

It was the reason Boost was founded, but once C++ standard absorbed most
of Boost foundational libraries, Boost needed a new purpose.  There was
much discussion of this around 2010ish but there wasn't much consensus,
and we just continued without really thinking about it.

>> But Boost itself shouldn't compromise on quality - in its review
>> process or what it ships in a Boost distribution,   to serve any of
>> those other interests.

The only reason boost was successful, and continues to be is that it's
one of the few places where one can acquire quality quality C++
libraries including code, tests, documentation, rationale, etc.  Vendor
supplied C++ standard libraries also fulfill this role.  But the C++
standard can't evolve fast enough and vendors couldn't keep up in any
case.  Hence the need for Boost.


> That is a decision for the Boost community to make, while there is still a
> community.  

That Boost must supply high quality software, and only such software,
has been a fundamental premise of Boost since it's inception.  The
decision was made long ago.  Of course the community could decide that
quality could be de-emphasized in order to promote some other value(s)
and that would be a decision for the community to make.  But so far I
don't recall anyone proposing that.

If all C++ library development goes elsewhere then there won't
> be much left.

Hmmm - I don't understand what that means.  Is C++ library development
going somewhere?

>> Putting a bunch of experimental libraries into a Boost release just
>> because people have proposed them for standardization is not something
>> we should do.

Hmmm - what does experimental mean in this context?  If means that
quality has been compromised to get the job finished, we shouldn't do
it.  If means some software which no one would ever think of putting
into the standard (symbolic differentiation?), I wouldn't have any
problem with it at all.  If someone want's to strike out with a whole
new direction for character encoding, I would OK with that.  But what I
would not be happy with is an incomplete/buggy/low quality of any of
these things.

People use boost because:
a) it's documented
b) it works
c) it has passed a review process which certifies the above

The above saves user time - which the fundamental thing that they care
about.

> I disagree.  Consider how painful it is for a c++ programmer that wants to
> contribute to the review proposed libraries for the C++ standard.  And by
> that I mean, go and use the implementation.  In my case I was doing this
> for c++20 -- it was super painful.  Aside from the time it took to go pull
> from different places, compiler support and library quality/robustness was
> all over the map.

How would Boost changing it's mission address this problem?

> After sleeping on it I like the idea more than ever -- so maybe I'll work
> on it.  And if Boost doesn't want to distribute it then it's more of the
> same mind share drain away from Boost.  I think it would be fine to ship
> the proposed elements outside the main distro until it went thru a normal
> review.  Ideally we'd get more authors to submit to a boost review and come
> under the tent.  Maybe we could have some of the 'boostification' work done
> by Summer of Code students.  Maybe this will led to more libraries like
> asio that can ship standalone and in Boost as well.

Note that the Boost Library Incubator (www.blincubator.com) was
conceived to fulfill a role similar to that which you describe.  The
requirements to be accepted into the incubator are objective and require
not subject review.  The web site could/should be simplified/updated as
much of the functionality is now better implemented within github
itself. But in principle it seems similar to what you have in mind.

> Understood, but we should care about his effort to standardize.  Unicode is
> hard, it's a mess in C++, and average programmers could use a Boost (sorry,
> so sorry, not sorry :).  Ideally what Zach proposes will ship under the
> Boost banner first.  Why?   So more than the maybe 20 people on the
> committee will look at it before the ink is dried and it ships with
> compilers.

All true, but it should be good enough to pass a boost review before the
committee decides to consider it.

Robert Ramey

PS: Off topic

TL;DR

The role, goals, methods, of the C++ library committee have been the
subject of much discussion of late.  To many of us, it seems very clear
that the process is not scaling and the committee as it currently
operates can't keep up while still maintaining the level of quality that
we and other users demand.  Something is going to have to change here,
but of course we can never agree.

RR

>
> Jeff
>
> _______________________________________________
> 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: Boost, not LEWG

Boost - Dev mailing list
On Sat, Jun 27, 2020 at 9:20 PM Robert Ramey via Boost <
[hidden email]> wrote:

> On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
> > On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost <
> > [hidden email]> wrote:
> >
>
> > It used to not just be a bonus -- it's the prime reason Boost exists.  If
> > it no longer has that mission we should make that clearer.
>
> It was the reason Boost was founded, but once C++ standard absorbed most
> of Boost foundational libraries, Boost needed a new purpose.  There was
>

I must have missed something bc I never got the change of mission memo --
despite being at 'future of boost' in Aspen every year.  Still, I mean it's
pretty clear that the mission has adjusted over time.   Part of the role
became supporting std library equivalents on older versions of the
standard.  Part of it is offering useful extensions that aren't in the
standard.  Part of it is offering useful libraries that won't ever go into
the standard.

But the original mission stands.  Before C++20 it was the case that a big
part of the new content was still rolling in older Boost libraries (aka
filesystem in 17).  Networking still hasn't made it there - it is a 23
priority.  Stacktrace might have a shot at 23 -- was close in 20, but ran
out of time. Peter and Glen moved some shared_ptr facilities into 20. I'm
helping to shepherd Process, because I believe that it should be there as
well.  So the pipeline isn't completely dead, but it's no longer the
primary input.


> > That is a decision for the Boost community to make, while there is still
> a
> > community.
>
> That Boost must supply high quality software, and only such software,
> has been a fundamental premise of Boost since it's inception.  The
> decision was made long ago.  Of course the community could decide that
> quality could be de-emphasized in order to promote some other value(s)
> and that would be a decision for the community to make.  But so far I
> don't recall anyone proposing that.
>
> If all C++ library development goes elsewhere then there won't
> > be much left.
>
> Hmmm - I don't understand what that means.  Is C++ library development
> going somewhere?
>

Yes it has -- standalone repos on github. As it stands, boost has NO
implementations of the c++20 major library changes (ranges, format, span,
chrono).  Maybe we will get jthread incorporated?  How about
synchronization primitives like barriers and semaphores? The container
erase algorithms?  Do we have scope_guard from the fundamentals TS that
someone might propose to go 23 - no we don't.  Will we have range library
extensions already being evaluated for 23 -- seems unlikely, given that we
don't have base ranges.  So the part of the community that in the past has
looked to Boost for 'bridge to a newer standard' is no longer being served
going forward.  And the part of the community looking at the future isn't
being served either.

Let me be clear that I'm not suggesting that we reduce quality and
consistency.  I'm just saying maybe we should think outside the box, like
you were with the incubator, for encouraging the rapid incorporation of
libraries proposed for the standard.  Maybe there needs to be some
concerted effort to make a case to library authors that it's worth their
time to be part of Boost. Maybe the path doesn't 'start' with the standard
review process.  Maybe it's a Boost23 package that can be unpacked on top
of the usual distro and has a set of boostified proposal libraries. If they
go through the review then they would just go into the distro of course.

>> Putting a bunch of experimental libraries into a Boost release just
> >> because people have proposed them for standardization is not something
> >> we should do.
>
> Hmmm - what does experimental mean in this context?  If means that
> quality has been compromised to get the job finished, we shouldn't do
> it.  If means some software which no one would ever think of putting
> into the standard (symbolic differentiation?), I wouldn't have any
> problem with it at all.  If someone want's to strike out with a whole
> new direction for character encoding, I would OK with that.  But what I
> would not be happy with is an incomplete/buggy/low quality of any of
> these things.
>
> People use boost because:
> a) it's documented
> b) it works
> c) it has passed a review process which certifies the above
>
> The above saves user time - which the fundamental thing that they care
> about.
>

Let's consider the format library which went into c++20.  It's substantial
and useful work moving output past i/o streams.  It's something that will
impact most c++ developers.  It's not in Boost, but in my view it would
have been even better if it had been in Boost.  There would have been more
scrutiny of some aspects earlier in the process.  The documentation would
have been better because a boost review would have forced that to happen.
And now there are extensions of that work being proposed -- but Boost isn't
in the loop at all.

Anyway, the 'implicit assumption' that the proposals and implementations
are necessarily of low quality bc they are not in Boost is incorrect.  But
as mentioned elsewhere the standard deviation is higher -- the level of
testing for most is clearly less bc they don't have 20 test runners on top
of the standard github CI to test their code.  Which means it may, or may
not actually compile and work in my environment.   Documentation is often a
casualty as the effort is in preparation of materials for the committee and
not for users.

> I disagree.  Consider how painful it is for a c++ programmer that wants to
> > contribute to the review proposed libraries for the C++ standard.  And by
> > that I mean, go and use the implementation.  In my case I was doing this
> > for c++20 -- it was super painful.  Aside from the time it took to go
> pull
> > from different places, compiler support and library quality/robustness
> was
> > all over the map.
>
> How would Boost changing it's mission address this problem?
>

I see it more as getting back to the core mission, but adapting to the new
realities.


> > After sleeping on it I like the idea more than ever -- so maybe I'll work
> > on it.  And if Boost doesn't want to distribute it then it's more of the
> > same mind share drain away from Boost.  I think it would be fine to ship
> > the proposed elements outside the main distro until it went thru a normal
> > review.  Ideally we'd get more authors to submit to a boost review and
> come
> > under the tent.  Maybe we could have some of the 'boostification' work
> done
> > by Summer of Code students.  Maybe this will led to more libraries like
> > asio that can ship standalone and in Boost as well.
>
> Note that the Boost Library Incubator (www.blincubator.com) was
> conceived to fulfill a role similar to that which you describe.  The
> requirements to be accepted into the incubator are objective and require
> not subject review.  The web site could/should be simplified/updated as
> much of the functionality is now better implemented within github
> itself. But in principle it seems similar to what you have in mind.
>

Yeah, I agree there's a similarity.  I think the difference is I'm thinking
of an entire collection of libraries and not a single proposal.


> > Understood, but we should care about his effort to standardize.  Unicode
> is
> > hard, it's a mess in C++, and average programmers could use a Boost
> (sorry,
> > so sorry, not sorry :).  Ideally what Zach proposes will ship under the
> > Boost banner first.  Why?   So more than the maybe 20 people on the
> > committee will look at it before the ink is dried and it ships with
> > compilers.
>
> All true, but it should be good enough to pass a boost review before the
> committee decides to consider it.
>

The reality of the order is different -- the committee is already looking
at it and that is informing the design.

Robert Ramey

>
> PS: Off topic
>
> TL;DR
>
> The role, goals, methods, of the C++ library committee have been the
> subject of much discussion of late.  To many of us, it seems very clear
> that the process is not scaling and the committee as it currently
> operates can't keep up while still maintaining the level of quality that
> we and other users demand.  Something is going to have to change here,
> but of course we can never agree.
>
> Sure -- scaling is hard.  And yeah, it's how the committee deals with that
is off topic for this list -- but it is clearly on committee members
minds.  On topic for this list is how WE, the boost community, deal with
that scaling and velocity of the current process in the committee.  Since
at least one of the missions is to in fact help said committee ensure the
highest quality library additions possible we might need some new
approaches in the current context.

Jeff

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland <[hidden email]> wrote:
> Being in std:: really is the ultimate c++ distro.

Yes well this attitude needs to change as it is obviously
unsustainable. Lowering Boost's acceptance bar doesn't sound like a
good way to solve this. Until this problem is addressed (among other
things) I prefer to do other more productive things, as the return on
my time investment in committee matters is lower than alternatives.

Thanks

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 12:24 PM Vinnie Falco  wrote:
>
> On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland wrote:
> > Being in std:: really is the ultimate c++ distro.
>
> Yes well this attitude needs to change as it is obviously
> unsustainable. Lowering Boost's acceptance bar doesn't sound like a
> good way to solve this.

+1.

Boost is a peer reviewed collection of libraries. Boost's success has
come from that peer review.

Just because Boost.X was peer reviewed and has built user trust,
sticking a "Boost." in front of "Y" to form "Boost.Y" just because Y
is proposed for the standard isn't right.

If "Y" wants to be part of Boost and be "Boost.Y", it should be
formally reviewed.

Now if you want to have "BoostExperimental.Y" then make a new project
called BoostExperimental but let's not shovel anything into the Boost
release distribution that wasn't peer reviewed.

If the problem being solved is unacceptable things being put into the
C++ standard library, and the idea is having them go through Boost
first, I like that. But that should mean going through Boost's formal
review process. Not being exempt just because they were proposed for
the standard.

The pathological case scenario is Boost's reputation and quality being
diminished and consequently Boost not being a viable means for those
proposed libraries to get user experience anyway.

Glen

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Jun 28, 2020 at 10:43 AM Jeff Garland via Boost <
[hidden email]> wrote:

> On Sat, Jun 27, 2020 at 9:20 PM Robert Ramey via Boost <
> [hidden email]> wrote:
>
> > On 6/27/20 3:46 PM, Jeff Garland via Boost wrote:
> > > On Sat, Jun 27, 2020 at 9:02 AM Glen Fernandes via Boost <
> > > [hidden email]> wrote:
> > >
> >
> > > It used to not just be a bonus -- it's the prime reason Boost exists.
> If
> > > it no longer has that mission we should make that clearer.
> >
> > It was the reason Boost was founded, but once C++ standard absorbed most
> > of Boost foundational libraries, Boost needed a new purpose.  There was
> >
>
> I must have missed something bc I never got the change of mission memo --
> despite being at 'future of boost' in Aspen every year.
>

Sorry to point this out.. But attending a face to face meeting is the least
beneficial way to get an assessment as to what the Boost developer and user
community state is.

--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- 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: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 10:18 AM René Ferdinand Rivera Morell <
[hidden email]> wrote:

> On Sun, Jun 28, 2020 at 10:43 AM Jeff Garland via Boost <
> [hidden email]> wrote:
>
>>
>> I must have missed something bc I never got the change of mission memo --
>> despite being at 'future of boost' in Aspen every year.
>>
>
> Sorry to point this out.. But attending a face to face meeting is the
> least beneficial way to get an assessment as to what the Boost developer
> and user community state is.
>

It's a data point. We have no scientific way to assess this unfortunately.
Regardless, the mission didn't change for me, and from my imperfect sample
some others as well.  Maybe there's only 5 of us anachronisms left -- but
it's more than zero.

Jeff

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Jun 28, 2020 at 9:24 AM Vinnie Falco via Boost <
[hidden email]> wrote:
>
> On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland <[hidden email]> wrote:
> > Being in std:: really is the ultimate c++ distro.
>
> Yes well this attitude needs to change as it is obviously
> unsustainable.

I guess it is obvious to some people but not others.

But reality will impose itself on C++. People will treat the standard
depending on what it actually is. If the committee continues the frantic
innovation and release of untested stuff, it'll be treated like the
immature product it actually is.

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 28 Jun 2020 at 19:40, Glen Fernandes via Boost
<[hidden email]> wrote:

>
> On Sun, Jun 28, 2020 at 12:24 PM Vinnie Falco  wrote:
> >
> > On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland wrote:
> > > Being in std:: really is the ultimate c++ distro.
> >
> > Yes well this attitude needs to change as it is obviously
> > unsustainable. Lowering Boost's acceptance bar doesn't sound like a
> > good way to solve this.
>
> +1.
>
> Boost is a peer reviewed collection of libraries. Boost's success has
> come from that peer review.
>
> Just because Boost.X was peer reviewed and has built user trust,
> sticking a "Boost." in front of "Y" to form "Boost.Y" just because Y
> is proposed for the standard isn't right.
>
> If "Y" wants to be part of Boost and be "Boost.Y", it should be
> formally reviewed.
>
> Now if you want to have "BoostExperimental.Y" then make a new project
> called BoostExperimental but let's not shovel anything into the Boost
> release distribution that wasn't peer reviewed.
>
> If the problem being solved is unacceptable things being put into the
> C++ standard library, and the idea is having them go through Boost
> first, I like that. But that should mean going through Boost's formal
> review process. Not being exempt just because they were proposed for
> the standard.
>
> The pathological case scenario is Boost's reputation and quality being
> diminished and consequently Boost not being a viable means for those
> proposed libraries to get user experience anyway.

Fully agreed. Lowering the bar of getting something into Boost doesn't
help anyone.

Some standard proposals come with the statement "this has been
accepted into Boost",
and some with "this has been shipping in Boost for N years". Those are
useful bits
of information. They become useless bits of information if Boost
starts accepting libraries
without peer review. They become worse than useless if Boost starts
accepting libraries
just because they are in the standard pipe, and I don't think anyone
has suggested that.

Boost can be a step on the way to include a library into the standard.
But it should be such
a step if and only if the expected-quality peer review that we've come
to expect from Boost takes place.
Boost is also not only such a step, it's more than that, so it
shouldn't be subservient to the purposes
of standardizing library proposals.

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

Re: Boost, not LEWG

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, Jun 28, 2020 at 11:40 AM Glen Fernandes via Boost
<[hidden email]> wrote:

>
> On Sun, Jun 28, 2020 at 12:24 PM Vinnie Falco  wrote:
> >
> > On Sat, Jun 27, 2020 at 4:36 PM Jeff Garland wrote:
> > > Being in std:: really is the ultimate c++ distro.
> >
> > Yes well this attitude needs to change as it is obviously
> > unsustainable. Lowering Boost's acceptance bar doesn't sound like a
> > good way to solve this.
>
> +1.
>
> Boost is a peer reviewed collection of libraries. Boost's success has
> come from that peer review.
>
> Just because Boost.X was peer reviewed and has built user trust,
> sticking a "Boost." in front of "Y" to form "Boost.Y" just because Y
> is proposed for the standard isn't right.
>
> If "Y" wants to be part of Boost and be "Boost.Y", it should be
> formally reviewed.
>
> Now if you want to have "BoostExperimental.Y" then make a new project
> called BoostExperimental but let's not shovel anything into the Boost
> release distribution that wasn't peer reviewed.
>
> If the problem being solved is unacceptable things being put into the
> C++ standard library, and the idea is having them go through Boost
> first, I like that. But that should mean going through Boost's formal
> review process. Not being exempt just because they were proposed for
> the standard.
>
> The pathological case scenario is Boost's reputation and quality being
> diminished and consequently Boost not being a viable means for those
> proposed libraries to get user experience anyway.

Raising issue on this list with the way WG21 does things accomplishes
nothing.  Our choices as a separate Boost entity are: 1) get involved
directly and individually with WG21 and fix things, for our individual
definitions of "fix"; and 2) accept the reality that WG21 actually
wants to move even faster than it already does* and make it easier for
Boost to accept new libraries before they are standardized, thereby
influencing the quality of those submissions.

* Based on polling of WG21 members at multiple WG21 meetings in the
last 2 years.

#1 relies on individual effort and ability.  Some cannot get the time
off for, or cannot afford, or cannot stand the process enough, to
attend WG21 meetings.

#2 is change we can actually effect.  The shape of that does not have
to be exactly what Jeff has proposed -- that's just one suggestion.
There is a perception among WG21 submitters that Boost is an opaque
and unwelcoming organization, whether deserved or not.  I don't
personally find it to be so, and maybe this is simply intellectual
intimidation as others in this thread have suggested.  Nevertheless,
that and certain technical considerations (Boost.Build for one)
prevent people from going through the hassle of submitting to Boost
before WG21.  I think we should focus on smoothing that process in
whatever way we think would be effective, if we want the output of
WG21 to be better, without getting directly involved with WG21.

Zach

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 11:56 AM Zach Laine via Boost <[hidden email]>
wrote:
> Raising issue on this list with the way WG21 does things accomplishes
> nothing.  Our choices as a separate Boost entity are: 1) get involved
> directly and individually with WG21 and fix things, for our individual
> definitions of "fix"; and 2) accept the reality that WG21 actually
> wants to move even faster than it already does* and make it easier for
> Boost to accept new libraries before they are standardized, thereby
> influencing the quality of those submissions.

I disagree. Boost does not need to do anything, the problem we're
discussing is a committee problem. Whether they see it this way or not,
this is the truth.

As long as the committee is willing to "standardize" innovation -- and
there's no indication that they intend to stop, if anything the process is
accelerating -- there is nothing we can do to have library authors go
through the hassle of Boost. Specifically, it is not clear to me that the
lower volume of Boost activity is a problem, nor I think we need to attract
the kind of developer who views Boost as an obstacle to getting their
library standardized ASAP.

This isn't something that can be fixed from within. The last thing we
should be doing is lower the bar in Boost.

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 2:42 PM Emil Dotchevski via Boost
<[hidden email]> wrote:

>
> On Sun, Jun 28, 2020 at 11:56 AM Zach Laine via Boost <[hidden email]>
> wrote:
> > Raising issue on this list with the way WG21 does things accomplishes
> > nothing.  Our choices as a separate Boost entity are: 1) get involved
> > directly and individually with WG21 and fix things, for our individual
> > definitions of "fix"; and 2) accept the reality that WG21 actually
> > wants to move even faster than it already does* and make it easier for
> > Boost to accept new libraries before they are standardized, thereby
> > influencing the quality of those submissions.
>
> I disagree. Boost does not need to do anything, the problem we're
> discussing is a committee problem. Whether they see it this way or not,
> this is the truth.

I agree that this is a WG21 problem.  It *is* the truth.  But so what?
 What does knowing that truth actually do?  If WG21 does not see
things this way, the fact that it is the truth is irrelevant.  Many
people have raised this issue in WG2 meetings.  It has fallen on deaf
ears, for a variety of reasons.  Again, knowing the truth and
revealing it on a mailing list will not change the behavior in the
LEWG meeting room.

> As long as the committee is willing to "standardize" innovation -- and
> there's no indication that they intend to stop, if anything the process is
> accelerating -- there is nothing we can do to have library authors go
> through the hassle of Boost.

Here I disagree.  I've had several people ask me how to submit things
to Boost in WG21 meetings, and I've given them a rundown, and offered
some degree of hand-holding.  When only one of them (JeanHeyd)
actually followed through, I asked the others why they did not.  I got
answers in line with the suggested changes I've mentioned in this
discussion.  Those changes won't get all WG21 submitters to use Boost,
but I think it will be better than 1/N.  Also, regaining the
reputation as *the* proving ground for future standard libraries would
help too.  That relies partially on getting WG21 submitters'
involvement, but also on doing as Jeff suggested earlier -- having
backported items from C++X in Boost for use in C++<X.

Note that all of these measures would enable more people to submit to
Boost, whether they were WG21 participants or not.

> Specifically, it is not clear to me that the
> lower volume of Boost activity is a problem

We seem to be getting lower and lower numbers of reviewers.  I think
that's a problem, and I think increasing the number of active
participants may help solve that (or at least I hope so).

> , nor I think we need to attract
> the kind of developer who views Boost as an obstacle to getting their
> library standardized ASAP.

I care about the quality of submissions to Boost, and I don't want to
lower that regardless of what WG1 does or does not do.  I also care
about stopping untested library additions from moving through LEWG.  I
think Boost *could* be a partial solution to that.  I don't think
those goals need to be at odds.

> This isn't something that can be fixed from within. The last thing we
> should be doing is lower the bar in Boost.

You're talking about two different things.  We can make it easier to
get into Boost (overcoming technical obstacles and better documenting
the process) without lowering the quality bar for reviews.

Zach

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 1:32 PM Zach Laine via Boost <[hidden email]>
wrote:
> > Specifically, it is not clear to me that the
> > lower volume of Boost activity is a problem
>
> We seem to be getting lower and lower numbers of reviewers.  I think
> that's a problem, and I think increasing the number of active
> participants may help solve that (or at least I hope so).

I agree that lower number of reviewers is a problem. I meant that it is not
clear if a lower number of submissions is a problem.

> > , nor I think we need to attract
> > the kind of developer who views Boost as an obstacle to getting their
> > library standardized ASAP.
>
> I care about the quality of submissions to Boost, and I don't want to
> lower that regardless of what WG1 does or does not do.  I also care
> about stopping untested library additions from moving through LEWG.  I
> think Boost *could* be a partial solution to that.  I don't think
> those goals need to be at odds.

They are not at odds, they're orthogonal.

Realistically, I think that the committee will continue to "standardize"
innovation, and there's nothing that can be done to stop that (I'd love to
be proven wrong).

Independently, we can work to make Boost better, though I am not sure how.
I agree that the mailing list is archaic, but it works great, and I don't
think it's an obstacle for anyone. Perhaps I'm wrong about this.

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 9:19 PM Emil Dotchevski wrote:
> Independently, we can work to make Boost better, though I am not sure how.
> I agree that the mailing list is archaic, but it works great, and I don't
> think it's an obstacle for anyone. Perhaps I'm wrong about this.

The concrete items mentioned that have been known to inhibit
participation appear to be:
- Mailing lists
- Boost.Build

Not sure what to do about the second.

I'm happy to help anyone (LEWG or otherwise) produce Jamfiles for
their prospective libraries for building, testing, and documentation
generation (if Doxygen, Asciidoc).

Glen

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

Re: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost <
[hidden email]> wrote:

> The concrete items mentioned that have been known to inhibit
> participation appear to be:
> - Mailing lists
> - Boost.Build
>
> Not sure what to do about the second.
>

It's easy.. Make it abundantly clear that a build system, *any* build
system, is expected or required for review. And one way to do that is to
*require* no build system for review. Because if your library can be
reviewed easily without a build system it means the portability of your
code is good. Anything else should be a red flag for reviewers.


PS. I'll keep living the dream when we don't distribute any build system
with our libraries. Or the alternate dream where we distribute with 5 or
more alternate build system specifications.

--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- 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: Boost, not LEWG

Boost - Dev mailing list
On Sun, Jun 28, 2020 at 6:50 PM René Ferdinand Rivera Morell via Boost <
[hidden email]> wrote:

>
> On Sun, Jun 28, 2020 at 8:26 PM Glen Fernandes via Boost <
> [hidden email]> wrote:
>
> > The concrete items mentioned that have been known to inhibit
> > participation appear to be:
> > - Mailing lists
> > - Boost.Build
> >
> > Not sure what to do about the second.
> >
>
> It's easy.. Make it abundantly clear that a build system, *any* build
> system, is expected or required for review. And one way to do that is to
> *require* no build system for review. Because if your library can be
> reviewed easily without a build system it means the portability of your
> code is good. Anything else should be a red flag for reviewers.
>
>
> PS. I'll keep living the dream when we don't distribute any build system
> with our libraries. Or the alternate dream where we distribute with 5 or
> more alternate build system specifications.

Perhaps we should require travis and appveyor for review, and nothing else.

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