Re: Boost Asset Stewardship Review from Ion

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2024-09-08 20:35:35

niedz., 8 wrz 2024 o 16:27 Christian Mazakas via Boost <
boost_at_[hidden]> napisał(a):

> On Fri, Sep 6, 2024 at 7:25 PM Ion Gaztañaga via Boost <
> boost_at_[hidden]> wrote:
>
> > I also perceive that Boost’s vitality has declined, although mailing
> > list posts might have declined in part because “high frequency”
> > interactions moved to Slack and some technical bug discussions to Github
> > issues. The mailing list remains the method for more formal interactions.
> >
> > It is true that many new libraries skip Boost now. Possible reasons:
> >
> > a) The technical level required to pass a review in Boost is very high
> >
>
> Hmm, maybe this was true more in the past. I've been less than impressed
> with more recent Boost reviews where it's basically, "Wow, I've never heard
> of Redis until 10 minutes ago but this library seems great!".
>

A very valid point. And let me offer my experience here.
I try to participate in all Boost reviews as a reviewer,but I can only
effectively do it for "simple" libraries:
* those that deal with simple business logic: decimal numbers, URLs, arsers
* those who only require the knowledge of C++: optional, variant, tuple,
mp11.
For those I can determine if they have optimal design, if they took care of
the corner cases, if they are exception-safe, if they use resources
excessively.

For libraries that require the knowledge of a complex internet protocol,
and then the familiarity with ASIO, this exceeds my resource constraints.
I had nothing to contribute to Boost.Redis, or Boost.MySQL. I think that
there Boost developers community may not help as you need experts from a
very narrow domain. The review in that case is focused on something
different: if the protocol is implemented correctly, if the full extent of
the protocol has been enabled. This is complex, and there is no time or
room for verifying things like exception safety or corner cases of the
interface.

I am also concerned if the different libraries built on top of Boost.ASIO
-- Beast, Redis, MySQL -- give a uniform, consistent experience. But there
is no way for me to verify it, as the protocols are too complex.

Bigger, more complex libraries you will get, the poorer the quality of the
Boost Review process. This is why I have great expectations for the
promised rewrite of the Boost.Beast library announced by Vinnie.

Regards,
&rzej;

>
> But to this end, I put the blame on the review wizards for allowing reviews
> where there's a strong lack of expertise by the reviewers.
>
>
> > I also prefer to set aside controversial issues like Codes of
> > Conduct (who defines “hate”/”harassment”/” inappropriate”? who enforces
> > it? etc.), because I don’t think will help increase participation in the
> > project.
> >
>
> A Code of Conduct shouldn't ever be controversial, especially because Boost
> has already had a de facto one for decades.
>
> https://www.boost.org/community/policy.html
>
> The problem is, if you named this code-of-conduct.html, it triggers a
> visceral reaction such as Andrey chudding out quite badly in my review
> thread.
>
> This kind of stuff just simply makes Boost look bad and incompatible with
> the modern programming landscape and culture. llvm and Linux both have
> codes of conduct and they're easily more important than Boost. A CoC is not
> the death of a project.
>
> - Christian
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>