On Wed, Mar 27, 2024 at 9:47 PM Vinnie Falco via Boost
I guess I'm confused. My understanding is that libraries are considered good candidates for the Boost collection based on meeting some or all of certain criteria:
* They offer useful, novel functionality not found elsewhere * The API is superior to other libraries that do similar things * The implementation is exceptionally performant * Solving a familiar problem in a particularly elegant fashion * The library is already popular and has field experience * The library offers C++ standard functionality for older compilers
If by "My understanding is" you mean to imply that those are general rules, you are mistaken. I know for a fact that the latter two would not get consent. Especially your criteria for popularity & field experience seems wrong to me. Let's just take boost.json: that would have gotten my endorsement with zero users, because it's just obviously a useful thing to have. Also, why does it need to be exceptional? If there were amazing json libraries and boost.json was just better in it's error handling and a better fit for boost it wouldn't be exceptional? Why would that hurt inclusion into boost? You can have your preferences and thus withhold an endorsement and recommend rejection during the review.
But some of the chatter on the mailing list suggests that the bar for a Boost library candidate is lower. That a library just needs to basically work, even if it duplicates functionality found elsewhere, or even if it does not have anything that one might hold up as an example of exceptional engineering.
Correct. Being a candidate gives the library author the opportunity to receive feedback and prepare for the actual review. Given that preparing for the boost review includes a lot of work that is only useful if the library gets accepted into boost, I find it a good idea to receive an endorsement early.
Boost libraries used to be cutting edge, to such an extent that they were adopted into the C++ Standard. And now the progress is in reverse. The Standard introduces a new component, and the Boost library follows (Boost.Charconv for example). In other cases I see libraries with few to no users limping into reviews, or absent discussions which question whether or not the bar for excellence is exceeded. When I used to participate in wg21 I complained about the "direct to standard" pipeline, where people would just write papers for the sake of it with no example code or real-world user experience. I have to wonder if we are not cultivating a "direct to Boost" pipeline by having relaxed or poorly-defined acceptance criteria.
It sounds like you'd like boost to be cutting edge yet have libraries that have field experience and a user base. Pick one. [...]
When I look at a proposed library I try to figure out what is great about it, how well it performs for its users (or even, does it have any users?), what part of the API is exceptionally well designed and ergonomic, but most importantly I want to ask: what makes this library stand out to the extent that it should be part of the library collection? What aspects of the library, if viewed by someone learning C++ or interested in improving their design skills, are inspirational?
Again, why does a library need to stand out? Why isn't it good enough to solve a real world problem in an excellent fashion? Why does it need to be exceptional, which implies it eclipses all competitors?
Is this overly demanding or exclusionary? Am I overthinking things? Should we be asking more of these types of questions and requiring better answers?
You should ask more targeted questions and accept answers. In case of the sqlite discussion your question was "Why isn't this more like SoCi?". You completely ignored me pointing out the category mistake and all the features sqlite has that set it apart from any other sqlite client library. I think category mistakes and lack of understanding of scope can lead to many frustrating discussions here. I am pretty sure that you're familiar with people asking why beast is such a complicated version of python's request. The same happened during the mysql, redis and mustache reviews. I think it's important to ask two questions: 1. Based on the scope the author chose, does this library make sense in boost? 2. Is the execution great? I don't think it's illegal to question the scope, but it's usually not helpful. The author usually has a good idea what should be in a library, like you limiting boost.json to not include other document formats, because a user can just provide his own parser. It's a choice that makes sense, so both criteria are fulfilled. I think a lot of tension arises when people don't consider the intended scope of a library, but rather assume the library's scope must be congruent with their use-case.
What is the criteria for determining if a library is good enough to become part of the collection?
It passes review. That's the criteria, and always will be.