Re: [Async] Naming land grab?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2023-10-08 22:37:53

On Sun, Oct 8, 2023 at 1:26 PM Klemens Morgenstern <
klemensdavidmorgenstern_at_[hidden]> wrote:

> Should I have rejected boost.url, which had the same amount of
> reviews?

Perhaps, you could have, and it would not have bothered me in the
slightest, because Boost.URL *already had users* and there were more coming
every day. In other words Boost.URL offered such compelling usability and
utility that it did not *need* to be part of the official Boost
distribution in order for other projects

> I also find the question "does it belong in boost" misguided. If it passed
> review, it belongs in boost.

That is probably true and helpful for most reviews but we are talking about
outliers. I was never given any instructions on what belongs in Boost.
There is no place anyone can go to answer this question for themselves. For
example, does a library with no users, no field experience, whose API is
not based on any other model, for which the intention is to "shove it in
Boost and see who uses it" qualify as "belonging in Boost?" I wish we knew.
The simple formula of "if it passed review, it belongs in boost" is
unfortunately not a healthy or sustainable model.

Libraries akin to async have been around in other languages for a very long
> time.... How big does the user-base need to be and how would this be
> measured
>

On this, we agree. That there is a need for *something* along the lines of
Boost.Klemens.Async, is not disputed. In fact, one could say that the
demand is so high, that Not-In-Boost.Klemens.Async should gain traction on
its own even without the need to be included in the distribution.

> Which grounds? Too few reviews? Because all the other things you brought
> up should be addressed during review
>

> I would really like a review wizard to clarify what valid grounds for
> disputing a review are.
>

Again I find myself in agreement here. The review process most of the time
"just works" but every so often we get just the right combination of review
manager, author, library, and "direct to Boost" philosophy on a
controversial tech that answering the question of "does this belong in
Boost" suddenly is not simple. And we end up with reviews that proclaim
acceptance if for no other reason than "coroutines are important and Boost
has to _do something_ about them" without any practical experience. I want
to stress that I am not saying every library needs field experience. This
is different from WG21 - where I believe that ANY proposed library-only
solution should bake for years. For Boost we do not need such a high bar.
But a controversial library from a particular author with a particular
review manager in a particular subject for which there is little to no
field experience, I think that it needs to prove itself.

If it was me proposing Boost.Async, and someone said "hey Vinnie you need
to get some users" I would simply withdraw my library from consideration
and spend the next year getting those users. That you are arguing with me
and not putting in the work to market your library and work with other
projects to get them to use it, is a red flag. I would make sure that when
my library goes up for review there is a cadre of existing users standing
with me and making their presence felt virtually ("accept this library or
we will become loud!"). Boost.Klemens.Async has no cadre of existing users.
No other project uses it. Basically this library is like an unhoused person
asking for handouts "please accept my library even though I have no users."
As a matter of pride I would never allow my hard work to limp into a review
with no support.

Thanks