Re: [boost] Two mqtt libraries

20 May 2024

      On 5/20/24 1:20 AM, Klemens Morgenstern via Boost wrote:
...
On Sun, May 19, 2024 at 2:27 AM Robert Ramey via Boost
 wrote:
...
I've been contacted by my friend and sometime collaborator Takatoshi
Kondo regarding his submission of a boost library:
https://github.com/redboltz/async_mqtt. It has received two
endorsements. He has asked me to be review manager and I'm inclined to
accept this request as he was very helpful to me during the refinement
of the boost serialization library.
There is also mqtt client library that is proposed to the Boost.
https://github.com/mireo/async-mqtt5 It also has endorsements and a
review manager.
I've been approached by the mireo authors and have volunteered to be
their review manager.
...
A cursory examination of the git hub pages suggest considerable overlap
between the two submissions.  In general, boost has discouraged the
acceptance of multiple libraries with this much overlap - and for good
reason.  An accepted library often becomes the canonical implementation
in large parts of the C++ world.  Having two high quality libraries that
do almost the same thing is not where we would like to be.
Who's deciding "too much overlap"? Shouldn't this be up to reviewers?
I don't think I said "too much overlap". It's true that I made only the 
most casual review of the two github sites.
...
In this case, mireo aims to be a safe & easy-to-use client library,
while redboltz is a protocol library that can also be used to build
servers.
So... is my impression that these libraries overlap correct or 
incorrect?  My concern is that this would create a conflict.  Am I wrong 
about this?  If they really do address different domains and could 
coexist within boost, perhaps only a name change is called for.  Feel 
free to enlighten me on this.
...
...
I would like to propose that we review both libraries simultaneously in
order to try to reach a consensus as to which, if either we want to
accept.  I know this is a difficult task, but I think it is important
that we do this.  It's going to be tough to reject a well written
library because a better one has been accepted.  But it would be worse
to reject a well written library merely because another one was
submitted first.  Normally I don't participate as a review manager as
I'm pretty bogged down in Boost stuff as it is.  But I'm willing to make
an exception in this case due to the importance of this case and my
strong personal ties to Takatoshi.  BTW - who is the review wizard these
days?  I presume that he will be the one making the decision about this.
What I would propose is that both libraries are review simultaneously
or back-to-back, but considered separate reviews.
This could lead to the acceptance of both libraries.  Would that be a 
problem?  If so, how would it be resolved?
...
A few thoughts:
- The review manager exchange notes and publish their decision at the
same time.
  - Yet, these are two different reviews.
  - Reviewers are encouraged (yet not forced) to review both libraries.
  - The RM of library B can take into account if a reviewer only
reviews library A
  - The RM can also take into account the result of the other review
(e.g. if it's a close call for A, but B is accepted overwhelmingly)
- If we do the reviews simultaneously, do we need an extended period?
  - Can the RM of A write a review or participate in the discussion for B?
I'm not sure what the boost review policy on this. I seem to recall the 
review manager participating in the discussion mostly to clarify 
misunderstandings.
...
- Should consensus between RMs be required? Or could both libraries
be accepted?
That's the question!!!

I think we're on the same page as having simutaneous reviews.  I would 
argue that the outcome should be one decision by one person.  Since it 
seems that you've volunteered to review both libraries, you'd be the 
logical person to be the review manager.  Thanks for volunteering.  I 
don't envy you the task.

Given that your much more knowledgable about the domain, I'd be curious 
on your opinion as two whether having both libraries in boost would be a 
good idea.

I would also like to mention that I think this kind of library is 
suitable for Boost.  I don't expect to see this in the standard and it 
seems there is need for it.  So boost might be the logical home for it.
...
...
Robert Ramey
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost