On Sun, Oct 8, 2023 at 9:00 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> 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