Re: [Async] Naming land grab?

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2023-10-08 18:08:37

niedz., 8 paź 2023 o 18:15 Vinnie Falco <vinnie.falco_at_[hidden]> napisał(a):

> 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?
>

Well, so far the results for this review have not been announced, so there
is nothing to dispute.

I had similar concerns for other libraries recently accepted to Boost:
Boost.MySQL, Boost.Redis. I cannot assess their quality or design, as they
are too big, and I am not an expert. They may be good, but even good
libraries do not necessarily belong to Boost. Are they sufficiently
general-purpose? Are we just giving a stump that a library meets a certain
level of quality of design and implementation? Or are we aiming at an
extended Standard Library?

Regards,
&rzej;

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