Re: [Async] Naming land grab?

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2023-10-08 16:15:18

On Sun, Oct 8, 2023 at 9:00 AM Andrzej Krzemienski via Boost <
boost_at_[hidden]> wrote:

> If I were reviewing the library now, after what I have learned from this
> thread, my recommendation would have been to reject the library for now, as
> it was the case when Boost was young, on the grounds that the programming
> model and the scope is not clear. It is still not clear to me, "when I
> should use this library". My best approximation is "when I already use
> Boost.ASIO (directly or indirectly) and I find its (ASIO's) interface too
> clumsy".
>

I trust your judgement even though I am not completely familiar with the
technical details of the argument presented.

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.

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.

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

As an active member of the Official C++ Slack Workspace I observed the
development process of Boost.Async, which unfolded roughly this way:

1. "Let's write a new library and propose it for Boost"
2. (work on library)
3. Propose for Boost

This can work when the author is a C++ savant like Peter Dimov but for
ordinary humans such as myself I think that authoring a library with the
intent of going "direct to Boost" is a recipe for yielding poor results. I
believe that at a minimum we should have required some field experience
before the review was scheduled, so that reviewers would have more
information to go on in terms of seeing how this library fits into the Asio
and coroutine ecosystem.

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?

Side note: Did you know that review results can be disputed? Because I
can't find this information on the website. I think we need to start
documenting the review process and formalizing some of these common law
rules, so that future reviews can be conducted at the high level of quality
befitting Boost.

Thanks,

Vinnie