[text] [review] Text formal review result

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

[text] [review] Text formal review result

Boost - Dev mailing list
Many thanks to Zach for submitting his third library, Text, for Boost
formal review. And thank you to the Boost community for participating.
You can jump to result at the end of this email.

The review period ran from June 11 to June 20 and we received a total
of four reviews (three within the period). I won't summarise
individual points, all reviews are accessible in the Boost list
archives.

1. Emil Dotchevski submitted an early review, on June 3. He voted to
accept the entire library with no conditions.
2. Rainer Deyke submitted a review on June 12. He voted to accept only
the Unicode algorithms.
3. Phil Endecott submitted a review on June 18. He voted to accept
only the UTF transcoding algorithms, and accept the Unicode layer
providing the license issue is resolved.
4. JeanHeyd Meneide submitted a review after the review period ended,
on June 21. He voted to accept the Unicode layer, and require that the
text layer (if accepted) use std::string instead.

I received no private reviews, but one email expressing concern about
the copyright issue and eligibility for review.

My thanks to Emil, Rainer, Phil, and JeanHeyd for your reviews. Thanks
also to Gavin Lambert, Vinnie Falco, Alexander Grund, Villie
Voutilainen, and everyone who participated in the discussion.

The following points had the most weight in the review result that follows:

1. No desire for the string layer

   The bar for a custom string type is high. On a minor note presents
incompatibilities with interfaces using std::string. On a major note a
string replacement should give users things they currently depend on
in std::basic_string. One of these is the ability to control dynamic
allocations. Another is working with strings larger than 2GB.

   Allocators are not only about performance; i.e. the argument that
supporting custom allocators would compromise the performance of the
implementation is not enough to justify their absence. Users have the
need to choose which area of dynamic memory their objects live in. In
some cases users have a requirement that all dynamic allocations go
through a custom (and stateful) allocator.

   JeanHeyd mentioned the now-deprecated wstring_convert functions
which, despite their shortcomings, were usable. I filed LWG 2226
(http://wg21.link/lwg2226) years ago while at Microsoft because we had
to reject its use in such a project where every dynamic allocation had
to support stateful allocators, and wstring_convert did not. The end
result was the developer reimplementing the functionality with proper
support for stateful allocators.

   Supporting customizing allocation doesn't necessarily have to
involve the current allocator model that containers or other standard
library allocator-aware facilities support. As long as it provides the
user with a similar level of control.

2. No strong acceptance for the text layer

   I won't repeat the points here. There was no strong desire
expressed to have the text layer in Boost. The compromise to have it
backed by std::string was still expressed in light of several
shortcomings.

3. Portions of the library under a non-BSL license

   Phil identified three cases where the library did not have
appropriate licensing. One was a simple omission, another has been
resolved by the relevant code being relicensed under the BSL, but the
other is still pending. We have a strict requirement for Boost
licensing of code and data in our libraries that ship in the Boost
distribution, and we cannot compromise on this. Zach understands this
(he's authored two successful Boost libraries) and I'm confident he
will address this.

4. A strong desire to have the Unicode layer in Boost

   Especially the encoding transcoding, the Unicode algorithms part of
the library was well received. The reviews - though small in number -
have convinced me of the value of accepting this layer of the library,
provided the submission in question (all code and data) is licensed
entirely under the BSL.

A minor issue:

1. For a library of this size (all three layers are of non-trivial
implementation size), I hoped for more reviews and participation.
Rather than extend the review period by an additional week, the
feedback received above lead me to believe that for Boost's and Zach's
benefit, the result below and the prescribed course of action would be
better:

The result of this review is to reject the Text library in its current
form, but to ask Zach to submit a subset of the library containing
only the Unicode layer for mini-review, incorporating the feedback
pertaining to it in this review. Where all of the code and data is
licensed only under the BSL.

The review wizard has the ability to grant a 5-day mini-review instead
of a full 10-day review, and I've petitioned Mateusz to grant that
Zach have this opportunity if he chooses for a second review of a
library with just the Unicode layer.

The text layer (backed by std::string, but ideally designed one that
does not inhibit use of custom allocators ) could be reviewed as a
separate library, to improve the chances of getting the Unicode
algorithms in the hands of Boost users.

My thanks once again to Zach for submitting his Text library for a
review, and I hope that the second time's the charm.

Glen

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Thu, Jun 25, 2020 at 11:10 PM Glen Fernandes via Boost
<[hidden email]> wrote:
>
> Many thanks to Zach for submitting his third library, Text, for Boost
> formal review. And thank you to the Boost community for participating.
> You can jump to result at the end of this email.

Thanks, Glen, for managing the review, and thanks to all the reviewers.

[snip]

> The result of this review is to reject the Text library in its current
> form, but to ask Zach to submit a subset of the library containing
> only the Unicode layer for mini-review, incorporating the feedback
> pertaining to it in this review. Where all of the code and data is
> licensed only under the BSL.

I intend to do so.  The Unicode layer is the most important part to me
as well, since I want to standardize something like the interfaces
there for C++23.  I may therefore change the name to Boost.Unicode,
too.

Zach

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Fri, Jun 26, 2020 at 10:43 AM Zach Laine via Boost
<[hidden email]> wrote:
> I want to standardize something like the interfaces there for C++23

Why are you targeting a particular release date? Is your development
strategy going to be different because you want to "get something in
to C++23" versus "I want to standardize something after it has
achieved sufficient field experience and maturity?"

Thanks

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, 26 Jun 2020 at 06:10, Glen Fernandes via Boost
<[hidden email]> wrote:
> [...]
> The result of this review is to reject the Text library in its current
> form, but to ask Zach to submit a subset of the library containing
> only the Unicode layer for mini-review, incorporating the feedback
> pertaining to it in this review. Where all of the code and data is
> licensed only under the BSL.

I have updated the review schedule with the results

> The review wizard has the ability to grant a 5-day mini-review instead
> of a full 10-day review, and I've petitioned Mateusz to grant that
> Zach have this opportunity if he chooses for a second review of a
> library with just the Unicode layer.

Speaking on behalf of myself and John Phillips (notified),
we are happy to grant the mini-review whenever it suits you.

Thank you Zach, Glen and the reviewers.

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: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 26, 2020 at 11:03 AM Vinnie Falco via Boost <
[hidden email]> wrote:
>
> On Fri, Jun 26, 2020 at 10:43 AM Zach Laine via Boost
> <[hidden email]> wrote:
> > I want to standardize something like the interfaces there for C++23
>
> Why are you targeting a particular release date? Is your development
> strategy going to be different because you want to "get something in
> to C++23" versus "I want to standardize something after it has
> achieved sufficient field experience and maturity?"

I was going to ask the same question. Nothing should be standardized that
isn't already the defacto standard. It isn't likely that between what's
left of 2020 and 2023 this library or any other will become the defacto
standard. I know this fails on deaf ears but it needs to be said.

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
Many Boost developers, including Zach (we've talked), share that view. But
the thing is most library authors are choosing to go straight to the
committee instead of coming through Boost these days.  It's already going
to take them several years of effort if they bypass Boost -- so you can see
the rationale for going around if coming through Boost could delay or
derail. Seems to me that Zach is taking a parallel track -- getting the
proposal into the committee and the study unicode group, but then bringing
it back to Boost for review and shakedown as well to ensure quality and
usage experience. And while it's clear that a bunch of members want to
improve unicode asap -- it's not necessarily a high priority:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0592r4.html

And now I'll say some fairly radical things. To me this just says that as
an organization we should consider alternate paths to boost adoption.  For
example, perhaps if a library is proposed for the standard it should
automatically be allowed to become a boost 'experimental library' that
would ship with releases.  The library might not be maintained by the paper
authors, but maybe we could coax more authors into realizing there's a
benefit to shipping here in the form of massive user exposure.   And we
could still have a review -- but maybe the experimental acceptance wouldn't
hinge on the results.

Jeff

On Fri, Jun 26, 2020 at 3:22 PM Emil Dotchevski via Boost <
[hidden email]> wrote:

> On Fri, Jun 26, 2020 at 11:03 AM Vinnie Falco via Boost <
> [hidden email]> wrote:
> >
> > On Fri, Jun 26, 2020 at 10:43 AM Zach Laine via Boost
> > <[hidden email]> wrote:
> > > I want to standardize something like the interfaces there for C++23
> >
> > Why are you targeting a particular release date? Is your development
> > strategy going to be different because you want to "get something in
> > to C++23" versus "I want to standardize something after it has
> > achieved sufficient field experience and maturity?"
>
> I was going to ask the same question. Nothing should be standardized that
> isn't already the defacto standard. It isn't likely that between what's
> left of 2020 and 2023 this library or any other will become the defacto
> standard. I know this fails on deaf ears but it needs to be said.
>
> _______________________________________________
> 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: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 26, 2020, 5:22 PM Emil Dotchevski via Boost <
[hidden email]> wrote:

> On Fri, Jun 26, 2020 at 11:03 AM Vinnie Falco via Boost <
> [hidden email]> wrote:
> >
> > On Fri, Jun 26, 2020 at 10:43 AM Zach Laine via Boost
> > <[hidden email]> wrote:
> > > I want to standardize something like the interfaces there for C++23
> >
> > Why are you targeting a particular release date? Is your development
> > strategy going to be different because you want to "get something in
> > to C++23" versus "I want to standardize something after it has
> > achieved sufficient field experience and maturity?"
>
> I was going to ask the same question. Nothing should be standardized that
> isn't already the defacto standard. It isn't likely that between what's
> left of 2020 and 2023 this library or any other will become the defacto
> standard. I know this fails on deaf ears but it needs to be said.
>

Unicode is an actual standard.  The std::ranges library is too.  Not de
facto standards, actual standards.

The Unicode layer of the proposed Boost.Text packages the Unicode
algorithms into a std::ranges-style API.  There is very little invention
going on here.

The text layer is a different matter.  That *is* an invention.  It is also
controversial, as the review demonstrated.  That is precisely why I was not
going to attempt to standardize any of it in the C++23 timeframe, even when
my plan was still to get it into Boost right away.  It needs time for
evaluation and revision -- perhaps several years.

I understand the concerns you have both raised, and I share them.  I'm one
of the few people in LEWG consistently asking "How many users does this
have?" and "Why didn't this go into Boost first?".  If I thought that
either the Unicode standard or the std::ranges work were not fully baked, I
might have reservations about the Unicode layer of Boost.Text.  The only
thing that might need baking is the exact subset of Unicode algorithms that
one needs to do useful work.  The review has pointed out some weak spots,
but if you look at the review, you'll notice that they're all additive.  I
expect all future changes to be additive, too, because there are not
variations of the Unicode algorithms.  There's a fixed set of them.  If we
were to standardize the existing Unicode layer today, we'd be able to use
it for a very, very long time.

You cannot say that with any certainty about most proposals to the standard
library, but then most such proposals are not based on an existing
international standard.  That's why the Unicode layer (and *only* the
Unicode layer) should be standardized in the C++23 timeframe.

Zach

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 26, 2020 at 6:05 PM Jeff Garland via Boost
<[hidden email]> wrote:

[snip]

> And now I'll say some fairly radical things. To me this just says that as
> an organization we should consider alternate paths to boost adoption.  For
> example, perhaps if a library is proposed for the standard it should
> automatically be allowed to become a boost 'experimental library' that
> would ship with releases.  The library might not be maintained by the paper
> authors, but maybe we could coax more authors into realizing there's a
> benefit to shipping here in the form of massive user exposure.   And we
> could still have a review -- but maybe the experimental acceptance wouldn't
> hinge on the results.

I don't know how this would work exactly, and I find it concerning
that we would essentially have a lower bar for stuff that is targeting
the standard, where it will eventually be chiseled into stone.

However, where we might improve would be in lowering the bar to entry
required just to submit a library for review.  These hurdles currently
exist:

- This list is not very welcoming.  One committee proposal I know of
that is exactly the right kind of thing for Boost did not submit to
Boost because they felt this list was rude and combative.  I don't
know the details, so I don't know if this particular complaint is
warranted.  More generally, this list is hard for outsiders to
penetrate; pretty good evidence for this is the fact that we have
posts here mostly from the usual suspects, and new voices don't appear
very often.  I have no suggested fixes for this, unfortunately.
- It can be hard to figure out how to submit to Boost, and once you
do, the process is pretty involved.  We've addressed part of this by
having a list of names of Boosters who have volunteered to act as
review managers for stuff targeting the standard.  Having yet more
people volunteer to walk people through the process, and/or better
document the process, would help here.  As one example, is getting
endorsements actually necessary?  The submission process page says
that it is, but that step seems to be skipped pretty often from what I
can tell.  Maybe I'm just not paying enough attention.
- The build system and other infrastructure is unlike anything
anywhere else, and super obscure, because it is not documented well
enough to do anything but copy/paste from an existing Boost lib.  We
could of course use something that is used more widely.

I want to see more std lib proposals come through Boost first, and I
think a lot of you do, too.  However, for that to happen at a larger
scale than what we're seeing today (which is me alone as far as I can
tell), we would need to sand off those rough edges I mentioned.  The
status quo is that it's simply so much easier to submit straight to
LEWG that only a crazy person would do otherwise (again, that would be
me).

I'm not willing to do this work.  I have too many irons in the fire as
it is working on committee stuff and Boost libs.  Perhaps someone here
will be sufficiently motivated to address some of these things.

Zach

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Fri, Jun 26, 2020 at 9:02 PM Zach Laine via Boost <[hidden email]>
wrote:

> - The build system and other infrastructure is unlike anything
> anywhere else, and super obscure, because it is not documented well
> enough to do anything but copy/paste from an existing Boost lib.  We
> could of course use something that is used more widely.
>

Not sure how many times it's been mentioned.. But build system integration
is not required, or expected, for the review.


> I want to see more std lib proposals come through Boost first, and I
> think a lot of you do, too.


I want less libs submitted to the standard. Which is not the same :-)


> However, for that to happen at a larger
> scale than what we're seeing today (which is me alone as far as I can
> tell), we would need to sand off those rough edges I mentioned.  The
> status quo is that it's simply so much easier to submit straight to
> LEWG that only a crazy person would do otherwise (again, that would be
> me).
>

I'm truly questioning myself if I should go on a rant now :-\


--
-- 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: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost <[hidden email]>
wrote:

>
> I don't know how this would work exactly, and I find it concerning
>

I don't either, but I think we should ponder it.  At a basic level maybe
some folks would volunteer to help an author 'boostify' a library.  Maybe
summer of code projects.


> that we would essentially have a lower bar for stuff that is targeting
> the standard, where it will eventually be chiseled into stone.
>

As you know, that is exactly the opposite of what I think -- if anything we
should raise the bar.  Part of that is on the committee itself to learn how
to reject.  And yet, it's clear that Ranges and Format aren't some half
baked idea -- and yet not via Boost.  Of course, Networking will likely be
the next big addition from Boost -- let's see adopted int Boost 1.36.
We're running out of decade+ old libraries to influence the standard.


> However, where we might improve would be in lowering the bar to entry
> required just to submit a library for review.  These hurdles currently
> exist:
>
> - This list is not very welcoming.  One committee proposal I know of
> that is exactly the right kind of thing for Boost did not submit to
> Boost because they felt this list was rude and combative.  I don't
> know the details, so I don't know if this particular complaint is
> warranted.  More generally, this list is hard for outsiders to
> penetrate; pretty good evidence for this is the fact that we have
> posts here mostly from the usual suspects, and new voices don't appear
> very often.  I have no suggested fixes for this, unfortunately.
>

Yes, this is unfortunate, and I likewise have no solution.

- It can be hard to figure out how to submit to Boost, and once you
> do, the process is pretty involved.  We've addressed part of this by
> having a list of names of Boosters who have volunteered to act as
> review managers for stuff targeting the standard.  Having yet more
> people volunteer to walk people through the process, and/or better
> document the process, would help here.  As one example, is getting
> endorsements actually necessary?  The submission process page says
> that it is, but that step seems to be skipped pretty often from what I
> can tell.  Maybe I'm just not paying enough attention.
>

idk if this is the main issue, but certainly might play a role.


> - The build system and other infrastructure is unlike anything
> anywhere else, and super obscure, because it is not documented well
> enough to do anything but copy/paste from an existing Boost lib.  We
> could of course use something that is used more widely.
>

There seems to be in progress at some level toward cmake -- but really it's
not that hard to adapt.


> I want to see more std lib proposals come through Boost first, and I
> think a lot of you do, too.


Not a question in my mind on that.


> However, for that to happen at a larger
> scale than what we're seeing today (which is me alone as far as I can
> tell), we would need to sand off those rough edges I mentioned.  The
> status quo is that it's simply so much easier to submit straight to
> LEWG that only a crazy person would do otherwise (again, that would be
> me).
>

I'm afraid you are correct, which is why I brought it up.  Maybe I'm
channeling Dave A and Beman here -- but I think self reflection is in
order.

I'm not willing to do this work.  I have too many irons in the fire as
> it is working on committee stuff and Boost libs.  Perhaps someone here
> will be sufficiently motivated to address some of these things.
>

I agree -- you're one of the few doing it right. I'm only opening a
discussion here so that maybe the dynamic can change.

Jeff

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost
<[hidden email]> wrote:
> This list is not very welcoming.
> that is exactly the right kind of thing for Boost did not submit to
> Boost because they felt this list was rude and combative.

Yes well this is what happens when you encourage everyone to play the
part of victim. Its a larger problem and not one that is specific for
Boost to solve.

> this list is hard for outsiders to penetrate
> ...
> I have no suggested fixes for this

I agree. I think the mailing-list format is an anachronism. I would
like to rebrand Boost and the website to be a more comprehensive
social media site with an emphasis on C++. Instead of a mailing list,
it should have a forum. And reviews would take place there. For
example each reviewed library would be its own sub-forum to hold the
review (and subsequent discussion and support if the library is
accepted), using a threaded discussion format.

Thanks

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Fri, Jun 26, 2020 at 11:28 PM Vinnie Falco <[hidden email]> wrote:

>
> On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost
> <[hidden email]> wrote:
> > This list is not very welcoming.
> > that is exactly the right kind of thing for Boost did not submit to
> > Boost because they felt this list was rude and combative.
>
> Yes well this is what happens when you encourage everyone to play the
> part of victim. Its a larger problem and not one that is specific for
> Boost to solve.

I really don't know if that is the right characterization or not,
because I don't know all the details.

> > this list is hard for outsiders to penetrate
> > ...
> > I have no suggested fixes for this
>
> I agree. I think the mailing-list format is an anachronism. I would
> like to rebrand Boost and the website to be a more comprehensive
> social media site with an emphasis on C++. Instead of a mailing list,
> it should have a forum. And reviews would take place there. For
> example each reviewed library would be its own sub-forum to hold the
> review (and subsequent discussion and support if the library is
> accepted), using a threaded discussion format.

I've been thinking the same thing for a number of years.

Zach

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Glen, thanks for managing the review.

Glen Fernandes wrote:
> 1. For a library of this size (all three layers are of non-trivial
> implementation size), I hoped for more reviews and participation.

Yes, I found this rather dispiriting. And predictably, we are now
seeing more words being written contemplating what has gone wrong
than were written during the review itself. To the people who want
to suggest how to improve things, I think the most useful thing you
could tell us is why you individually did not submit a review.

While preparing my review I looked at the mailing list archive
from the time of the Boost.Locale review, and it is striking how
much quieter this list is now than a few years ago. Perhaps this
is simply because std::C++ now has things like shared_ptr and
tuple and optional etc. which a decade ago required Boost - if
fewer people now need to use Boost then there are fewer people
here to submit reviews. Which is a good thing, maybe. Does anyone
know if the number of list subscribers has declined over the years?


Zach Laine wrote:
> The status quo is that it's simply so much easier to submit
> straight to LEWG that only a crazy person would do otherwise
> [i.e. to Boost]

I'm surprised by the suggestion that it's easier to work with
the standards committees than with Boost. For a start, literally
anyone can subscribe to this list and engage with discussions
free of charge. According to isocpp.org/std/meetings-and-participation,
the policy for access to the WG21 email lists is they are open to:

* Any member of a national body that participates in WG21,
including any employee of a company that is already a member of
a national body. [Cost: $1,950 per year in the US.]

* Any person who has already attended a face-to-face meeting in
the past. This requirement helps preserve the signal-to-noise
ratio by limiting access to people who have demonstrated they're
serious about participating. ["Serious about participating", or
"rich and like intercontinental travel and don't believe in
climate change"?]

* (new) For a Study Group email list, the SG chair may also at
their own discretion add any new expert who wants to participate.
In particular, SGs are especially designed to be open and
inclusive to experts in their field. [So if I were an "expert"
in Unicode - which I'm not! - I could ask the Unicode SG chair
to add me, which they may or may not do at their discretion.]

I really don't see how that could possibly be easier, or (in
reference to another part of Zach's message) more welcoming
than Boost!


Regards, Phil.





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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Sat, Jun 27, 2020 at 7:58 AM Phil Endecott via Boost
<[hidden email]> wrote:
> the most useful thing you  could tell us is why you
> individually did not submit a review.

I suck at writing reviews. I look at other people's reviews and they
are amazing, well thought out, and demonstrate a deep understanding of
library design and C++. While I have a short attention span and lack
the patience to evaluate someone else's library. As such it is my
preference simply to remain silent, unless there is a very narrow
topic that I am confident speaking about (such as allocator support in
string containers).

I try to make up for it by encouraging my co-workers to submit
reviews. However no one was knowledgeable in Unicode.

> it is striking how much quieter this list is now than a few years ago.
> Perhaps this is simply because std::C++ now has things like shared_ptr and
> tuple and optional etc. which a decade ago required Boost

I think it is because there is no one tasked with promoting Boost and
doing public relations work.

Thanks

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 6/26/2020 10:02 PM, Zach Laine via Boost wrote:

> On Fri, Jun 26, 2020 at 6:05 PM Jeff Garland via Boost
> <[hidden email]> wrote:
>
> [snip]
>
>> And now I'll say some fairly radical things. To me this just says that as
>> an organization we should consider alternate paths to boost adoption.  For
>> example, perhaps if a library is proposed for the standard it should
>> automatically be allowed to become a boost 'experimental library' that
>> would ship with releases.  The library might not be maintained by the paper
>> authors, but maybe we could coax more authors into realizing there's a
>> benefit to shipping here in the form of massive user exposure.   And we
>> could still have a review -- but maybe the experimental acceptance wouldn't
>> hinge on the results.
>
> I don't know how this would work exactly, and I find it concerning
> that we would essentially have a lower bar for stuff that is targeting
> the standard, where it will eventually be chiseled into stone.
>
> However, where we might improve would be in lowering the bar to entry
> required just to submit a library for review.  These hurdles currently
> exist:
>
> - This list is not very welcoming.  One committee proposal I know of
> that is exactly the right kind of thing for Boost did not submit to
> Boost because they felt this list was rude and combative.  I don't
> know the details, so I don't know if this particular complaint is
> warranted.  More generally, this list is hard for outsiders to
> penetrate; pretty good evidence for this is the fact that we have
> posts here mostly from the usual suspects, and new voices don't appear
> very often.  I have no suggested fixes for this, unfortunately.
> - It can be hard to figure out how to submit to Boost, and once you
> do, the process is pretty involved.  We've addressed part of this by
> having a list of names of Boosters who have volunteered to act as
> review managers for stuff targeting the standard.  Having yet more
> people volunteer to walk people through the process, and/or better
> document the process, would help here.  As one example, is getting
> endorsements actually necessary?  The submission process page says
> that it is, but that step seems to be skipped pretty often from what I
> can tell.  Maybe I'm just not paying enough attention.
> - The build system and other infrastructure is unlike anything
> anywhere else, and super obscure, because it is not documented well
> enough to do anything but copy/paste from an existing Boost lib.  We
> could of course use something that is used more widely.
>
> I want to see more std lib proposals come through Boost first, and I
> think a lot of you do, too.  However, for that to happen at a larger
> scale than what we're seeing today (which is me alone as far as I can
> tell), we would need to sand off those rough edges I mentioned.  The
> status quo is that it's simply so much easier to submit straight to
> LEWG that only a crazy person would do otherwise (again, that would be
> me).

You have raised a bunch of hackles here. The LEWG, along with all other
C++ standard committees, seems to me so much less open to debate than
Boost is that it is hard to know what to say about your assertion that
"This list is not very welcoming". Nor can anything ever be found out
from the C++ standards committee why such and such was accepted or
rejected, or what the arguments were about after the fact. Finally the
poobahs of the C++ standard committee I have often found to be largely
unfriendly and closed in their determination that only they really know
what is good or not for C++.


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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost
<[hidden email]> wrote:
> You have raised a bunch of hackles here. The LEWG, along with all other
> C++ standard committees, seems to me so much less open to debate than
> Boost is that it is hard to know what to say about your assertion that
> "This list is not very welcoming". Nor can anything ever be found out
> from the C++ standards committee why such and such was accepted or
> rejected, or what the arguments were about after the fact.

Have you tried asking a committee member, or just asking on std-discussion?
It also seems to me that there tends to be a multitude of meeting trip reports
that cover why such and such was accepted or rejected.

> poobahs of the C++ standard committee I have often found to be largely
> unfriendly and closed in their determination that only they really know
> what is good or not for C++.

Sure; some of them need a fairly strong rationale to be convinced otherwise. :)

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-27 05:02, Zach Laine via Boost wrote:
> On Fri, Jun 26, 2020 at 6:05 PM Jeff Garland via Boost
> <[hidden email]> wrote:
>
> However, where we might improve would be in lowering the bar to entry
> required just to submit a library for review.  These hurdles currently
> exist:
>
> - This list is not very welcoming.

Personally, I like Boost ML very much, compared to some other mailing
lists I'm subscribed to. It has been very professional, technical and
helpful over the years that I'm participating, with remarkably little
spam, politics, rudeness and personal attacks.

I can see it could be intimidating for newcomers to join because of the
level of technical scrutiny this list exercises. But that scrutiny
ultimately leads to better libraries, which I think is a good thing.

> One committee proposal I know of
> that is exactly the right kind of thing for Boost did not submit to
> Boost because they felt this list was rude and combative.  I don't
> know the details, so I don't know if this particular complaint is
> warranted.  More generally, this list is hard for outsiders to
> penetrate; pretty good evidence for this is the fact that we have
> posts here mostly from the usual suspects, and new voices don't appear
> very often.  I have no suggested fixes for this, unfortunately.

It is true that ML activity has reduced lately, but I suspect that some
amount of discussions have simply migrated to other platforms, like
GitHub and Slack.

Specifically on GitHub, I'll note that some of the bad reputation of
Boost comes from the lack of support of some libraries. People create
issues and PRs that are left unattended for years, which gives a bad
impression of Boost as a whole.

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-27 07:27, Vinnie Falco via Boost wrote:

> On Fri, Jun 26, 2020 at 7:02 PM Zach Laine via Boost
> <[hidden email]> wrote:
>> This list is not very welcoming.
>> that is exactly the right kind of thing for Boost did not submit to
>> Boost because they felt this list was rude and combative.
>
> Yes well this is what happens when you encourage everyone to play the
> part of victim. Its a larger problem and not one that is specific for
> Boost to solve.
>
>> this list is hard for outsiders to penetrate
>> ...
>> I have no suggested fixes for this
>
> I agree. I think the mailing-list format is an anachronism. I would
> like to rebrand Boost and the website to be a more comprehensive
> social media site with an emphasis on C++. Instead of a mailing list,
> it should have a forum.

IMHO, forums are much less convenient and interactive. All you need to
use an ML (or multiple MLs) is an email client with a decent filtering
system (which may also be implemented on the server). Whereas a forum is
project-specific (meaning if you have 5 forums, you go to 5 different
places, each having its own auth, UI, etc.), and you need to actively
check it in a browser from time to time. (Email notifications exist, but
they are not equivalent to a ML as they are less interactive and don't
notify of new topics.)

I don't mind having a forum as an additional communication platform, if
there is demand, but it should not replace the ML.

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
On Sat, Jun 27, 2020 at 12:40 PM Andrey Semashev via Boost
<[hidden email]> wrote:
> I don't mind having a forum as an additional communication platform, if
> there is demand, but it should not replace the ML.

Mailing list sucks. People that are not subscribed can't search
through messages, and even people who are subscribed do not have
access to messages from before they subscribed. Google doesn't index
the mailing list, unless there is a mirror. In the case of Boost, the
mirror is controlled by third parties and cannot be leveraged to
generate traffic for boost.org and raise interest.

The barrier for joining a mailing list just to ask one question is
high. Right from the beginning you have to wait to get approved, and
then you need to wait for approval to post. In a forum, you can post a
message, get the URL of the message you just posted, and then share
that with your friends out-of-band (for example, on Slack or in a
reddit post) and get attention with possible replies right away. You
can't do that with a mailing list.

With a forum, information can be grouped in a top down fashion for
everyone. For example, we could create a subforum for each library
being reviews, have the review take place entirely in the forum, and
the forum is then locked and archived, available permanently through
boost.org (and associated with the library as part of its social media
history). At any point in the future someone could look through the
original review for the library including everyone's questions and
comments. They can share a link to the review subforum with their
friends. Someone can write a blog post years later about the review
and describe their experience, or lessons learned, or tout the great
value of the Boost Review Process, and so on. These things are not
possible with a mailing list.

We absolutely should move to a forum on boost.org for all things,
import as much as we can from the mailing list (as far back as
possible) into the forum, and then cease the use of the mailing list
forever. Anyone who emails the list should get an automated reply that
says "Please register for the wonderful forums at boost.org" etc

Thanks

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

Re: [text] [review] Text formal review result

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-27 20:55, Ville Voutilainen via Boost wrote:

> On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost
> <[hidden email]> wrote:
>> You have raised a bunch of hackles here. The LEWG, along with all other
>> C++ standard committees, seems to me so much less open to debate than
>> Boost is that it is hard to know what to say about your assertion that
>> "This list is not very welcoming". Nor can anything ever be found out
>> from the C++ standards committee why such and such was accepted or
>> rejected, or what the arguments were about after the fact.
>
> Have you tried asking a committee member, or just asking on std-discussion?

Asking a committee member requires personal interaction, and you have to
know who to ask in the first place. Personal interaction is
understandably a strong barrier for some.

Asking on std-discussion or std-proposals is a possibility. I have tried
that a few times, with mixed success. I suspect, a lot of proposal
authors don't actively monitor these lists for questions or comments
regarding proposals beyond the initial discussion phase, and committee
members are either too busy, or not involved in the proposal, or don't
reply for any other reason.

As someone who haven't attended the committee meetings personally, but
prepared a proposal with a representative, I can say that even obtaining
the results of discussion of your own proposal is difficult.

It is a very reasonable request to have a public searchable access to
the result of review and discussion of a given proposal, if only to be
able to learn from it or point to when another person comes up with a
similar proposal. It may be difficult to implement, but the demand is there.

> It also seems to me that there tends to be a multitude of meeting trip reports
> that cover why such and such was accepted or rejected.

Trip reports do not provide that information beyond the general results
of the most prominent proposals. They do not contain the discussion
results on every proposal. Besides, a trip report is a perspective of a
single person, who may have not even participated in the proposal you're
interested in. You'd have to search multiple personal blogs to find such
reports, among other posts, from multiple persons, with no certainty
you'll find the information you need in the first place.

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