Re: [Async] Naming land grab?

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-08 20:25:55

>
> That said, I believe that the review for this particular library is flawed,
> and I question the decision to accept.
>
> There are an insufficient number of reviews, the scope of the library is
> not clear, and furthermore there is no clarity with respect to answering
> the question "what belongs in Boost?" Ask five different people on the list
> and you will get five different answers. If there is no documented
> explanation of what belongs in Boost then the outcomes of certain reviews
> are going to be highly unpredictable, especially those where there is
> controversy.
>

Should I have rejected boost.url, which had the same amount of
reviews? There are more libraries with seven or less reviews in boost,
boost.lambda2 had 6.
If we introduce a lower limit,
Also, isn't a "REJECT, I don't think it belongs in boost" a fair review?

>
> In some cases the answer to what belongs in Boost is obvious.
> Implementations of standard library features for older versions of C++ are
> an example of something that obviously belongs in Boost. A library modeled
> on an existing 3rd party library but polished up to Boost quality and
> working with other Boost libraries (e.g. boost::system::error_code) is
> another: Boost.JSON.

Why is the second obvious?

I also find the question "does it belong in boost" misguided.
If it passed review, it belongs in boost. You are free to write a
short review rejecting it
and the review manager is free to disregard

>
> But then we have novel libraries for which reviewers have no template, no
> guidance, no existing practice to understand whether or not something
> belongs in Boost, and I believe Boost.Klemens.Async is the perfect example
> of such a library. This is my opinion, but I believe in these cases that
> the proper course of action is for the author to "do the work" of going out
> into the community and establishing a user base for the library before
> submitting it for review (as I have done with Beast and URL).

That's not really true. Libraries akin to async have been around in
other languages for a very long time.
Then there is also cppcoro and the coroutine types existing in asio.

How big does the user-base need to be and how would this be measured?

>
> Andrzej: There is a process for disputing the results of a review, by
> reporting the concerns to the Review Wizard. I would like to dispute the
> review result, on the grounds mentioned above, and if you still feel
> strongly about rejecting the library for the aforementioned reasons then I
> suggest you also dispute the review results. This goes for everyone on the
> list. Who is the Review Wizard for this review?

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.