niedz., 8 wrz 2024 o 16:27 Christian Mazakas via Boost < boost@lists.boost.org> napisał(a):
On Fri, Sep 6, 2024 at 7:25 PM Ion Gaztañaga via Boost < boost@lists.boost.org> 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