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. 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. 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. Robert Ramey
On Sun, May 19, 2024 at 2:27 AM Robert Ramey via Boost <boost@lists.boost.org> 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? 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.
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. 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? - Should consensus between RMs be required? Or could both libraries be accepted?
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 <boost@lists.boost.org> 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
On Mon, May 20, 2024 at 10:06 PM Robert Ramey via Boost <boost@lists.boost.org> wrote:
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 <boost@lists.boost.org> 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.
They do overlap substantially, but not a 100%. It's borderline I'd say.
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?
Well I personally would not consider that a problem if that's the result of the review.
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.
I only volunteered for the mireo library (i.e. the "other" one from your perspective). I don't think redboltz is ready for review so I don't want to be RM. Furthermore I fear I might be too biased between the two of the libraries to be review manager of both.
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.
Well, I think in the case of mqtt having a pure protocol library isn't as useful (as opposed to something as common as http). I also think mireo's mqtt client library has a much higher acceptance chance during review. Additionally I don't know if there's a lot of interest in an mqtt server library, but if there is, maybe it's worth exploring and turning redboltz into a server & protocol library. But that would require other people to endorse it. I am just convinced that an mqtt client would be incredibly useful for lots of IoT applications.
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.
That's why I endorsed redboltz library. I think having an asio-based mqtt library in boost makes perfect sense as I consider boost a good home for any asio-based lib since the networking TS was terminated.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, Regarding the overlap: I don't think it would be a problem. This is already in boost. Statemachine and MSM. Serialization and JSON. Statemachine and MSM both serve the exact same purpose. Serialization and JSON are not the same but I can use JSON to serialize my stuff with the from/to struct helper (don't remember the exact name right now) Bye Georg
On 5/22/24 3:14 AM, Georg Gast via Boost wrote:
Hi,
Regarding the overlap: I don't think it would be a problem. This is already in boost. Statemachine and MSM. Serialization and JSON.
Statemachine and MSM both serve the exact same purpose.
Actually, that is the iconic example of the situation I'd prefer to avoid. Statemachine was accepted. MSM was also accepted a short time later. MSM used more compile time techniques so it was preferred by many. Had they been reviewed together, we might have had a slightly simpler boost. Serialization and JSON are not the same but I can use JSON to serialize my stuff with the from/to struct helper (don't remember the exact name right now) FWIW - I don't think Serialization and JSON overlapp much if at all.
Bye Georg
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Jun 21, 2024 at 3:10 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 5/22/24 3:14 AM, Georg Gast via Boost wrote:
Hi,
Regarding the overlap: I don't think it would be a problem. This is already in boost. Statemachine and MSM. Serialization and JSON.
Statemachine and MSM both serve the exact same purpose.
Actually, that is the iconic example of the situation I'd prefer to avoid.
It's been over a month, shall we schedule the double-review with us both as review managers?
On 7/26/24 8:55 AM, Klemens Morgenstern via Boost wrote:
On Fri, Jun 21, 2024 at 3:10 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 5/22/24 3:14 AM, Georg Gast via Boost wrote:
Hi,
Regarding the overlap: I don't think it would be a problem. This is already in boost. Statemachine and MSM. Serialization and JSON.
Statemachine and MSM both serve the exact same purpose.
Actually, that is the iconic example of the situation I'd prefer to avoid.
It's been over a month, shall we schedule the double-review with us both as review managers?\
I don't think that having two review managers is a good idea. Were we to disagree, it might lead to compromise which the current system avoids. I also have a personal relationship with Takatoshi which might cloud my judgement or might lead others to question my objectivity. That is, I trust your judgement more than our judgement. I CAN promise that if you take on the job of review manager of the two libraries, I will make a serious commitment to reviewing both - each in the context of the other. That is, I will do what I can to make your life as easy as I can. I hope others can do the same. Robert Ramey
It's been over a month, shall we schedule the double-review with us both as review managers?\
I don't think that having two review managers is a good idea. Were we to disagree, it might lead to compromise which the current system avoids. I also have a personal relationship with Takatoshi which might cloud my judgement or might lead others to question my objectivity. That is, I trust your judgement more than our judgement. I CAN promise that if you take on the job of review manager of the two libraries, I will make a serious commitment to reviewing both - each in the context of the other. That is, I will do what I can to make your life as easy as I can. I hope others can do the same.
Alright let me state it more clearly: I will not be the review manager of redboltz/async_mqtt. I have not volunteered for that. I committed to be the review manager for mireo and I opted to wait with scheduling their review as a courtesy for Takatoshi, so the timing isn't the deciding factor. I do however think that a very long delay becomes unfair towards the mireo team. Unless we find a review manager for redboltz soo, I'd just stick to the official rules and schedule a regular review for mireo/async-mqtt5. They've been pretty much ready for review since late April.
On 7/26/24 6:47 PM, Klemens Morgenstern via Boost wrote:
It's been over a month, shall we schedule the double-review with us both as review managers?\
I don't think that having two review managers is a good idea. Were we to disagree, it might lead to compromise which the current system avoids. I also have a personal relationship with Takatoshi which might cloud my judgement or might lead others to question my objectivity. That is, I trust your judgement more than our judgement. I CAN promise that if you take on the job of review manager of the two libraries, I will make a serious commitment to reviewing both - each in the context of the other. That is, I will do what I can to make your life as easy as I can. I hope others can do the same.
Alright let me state it more clearly: I will not be the review manager of redboltz/async_mqtt. I have not volunteered for that.
I committed to be the review manager for mireo and I opted to wait with scheduling their review as a courtesy for Takatoshi, so the timing isn't the deciding factor. I do however think that a very long delay becomes unfair towards the mireo team.
Unless we find a review manager for redboltz soo, I'd just stick to the official rules and schedule a regular review for mireo/async-mqtt5. They've been pretty much ready for review since late April.
A very understandable position. My concern was to avoid the possibility of having two similar and/or conflicting libraries which has happened before. How about relaying this discussion to the "Boost Review Wizard" who is the designated person for scheduling reviews. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Let me clarify the status of async_mqtt. I am ready for the formal review and I informed my review manager, Robert Ramey, on June 21st. As the author of one of the libraries, I will leave the management of the review process up to the review managers. I trust that the process will be conducted fairly. ---- Thanks, Takatoshi Kondo 2024年7月27日(土) 13:31 Robert Ramey via Boost <boost@lists.boost.org>:
On 7/26/24 6:47 PM, Klemens Morgenstern via Boost wrote:
It's been over a month, shall we schedule the double-review with us both as review managers?\
I don't think that having two review managers is a good idea. Were we to disagree, it might lead to compromise which the current system avoids. I also have a personal relationship with Takatoshi which might cloud my judgement or might lead others to question my objectivity. That is, I trust your judgement more than our judgement. I CAN promise that if you take on the job of review manager of the two libraries, I will make a serious commitment to reviewing both - each in the context of the other. That is, I will do what I can to make your life as easy as I can. I hope others can do the same.
Alright let me state it more clearly: I will not be the review manager of redboltz/async_mqtt. I have not volunteered for that.
I committed to be the review manager for mireo and I opted to wait with scheduling their review as a courtesy for Takatoshi, so the timing isn't the deciding factor. I do however think that a very long delay becomes unfair towards the mireo team.
Unless we find a review manager for redboltz soo, I'd just stick to the official rules and schedule a regular review for mireo/async-mqtt5. They've been pretty much ready for review since late April.
A very understandable position. My concern was to avoid the possibility of having two similar and/or conflicting libraries which has happened before. How about relaying this discussion to the "Boost Review Wizard" who is the designated person for scheduling reviews.
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, Jul 27, 2024 at 3:49 PM Takatoshi Kondo via Boost <boost@lists.boost.org> wrote:
Let me clarify the status of async_mqtt. I am ready for the formal review and I informed my review manager, Robert Ramey, on June 21st. As the author of one of the libraries, I will leave the management of the review process up to the review managers. I trust that the process will be conducted fairly.
Do you think fairness requires a simultaneous review with mireo/async_mqtt5 ? Or would a regular review of just your library suffice?
---- Thanks, Takatoshi Kondo
2024年7月27日(土) 13:31 Robert Ramey via Boost <boost@lists.boost.org>:
The simplest way to resolve this is to just review each library and deal with results independently. I suspect that both libraries will be acceptable to Boost. So my question is: What happens if both libraries get accepted? Do we add both libraries? - again the simplest resolution. This satisfies the authors and reviewers and would be suggested by my understanding of the Boost "Rules". But is it the best for Boost and Boost users? Wouldn't this be a source of confusion amongst the later. Boost has claimed to provide the best implementations of commonly used C++ library components. How could we continue to claim this if we have more than one library making this claim about some problem domain. I'm also disturbed that it seems that I'm only person concerned about this. Am I out of touch here - if so how. We have elements such as the Review Wizard(s) and Steering Committee (still?), Boost Foundation(?), informal group of boost senior or privileged developers to address these "edge cases". Is no one willing to speak up here? Robert Ramey
On Sun, 28 Jul 2024, 23:02 Robert Ramey via Boost, <boost@lists.boost.org> wrote:
I'm also disturbed that it seems that I'm only person concerned about this. Am I out of touch here - if so how. We have elements such as the Review Wizard(s) and Steering Committee (still?), Boost Foundation(?), informal group of boost senior or privileged developers to address these "edge cases". Is no one willing to speak up here?
I'm no authority here but from a user perspective, I think it makes more sense to have just one. Ruben.
On 7/29/24 00:01, Robert Ramey via Boost wrote:
The simplest way to resolve this is to just review each library and deal with results independently.
I suspect that both libraries will be acceptable to Boost. So my question is: What happens if both libraries get accepted?
Do we add both libraries? - again the simplest resolution.
This satisfies the authors and reviewers and would be suggested by my understanding of the Boost "Rules". But is it the best for Boost and Boost users? Wouldn't this be a source of confusion amongst the later. Boost has claimed to provide the best implementations of commonly used C++ library components. How could we continue to claim this if we have more than one library making this claim about some problem domain.
I'm also disturbed that it seems that I'm only person concerned about this. Am I out of touch here - if so how. We have elements such as the Review Wizard(s) and Steering Committee (still?), Boost Foundation(?), informal group of boost senior or privileged developers to address these "edge cases". Is no one willing to speak up here?
Not having looked at either of the libraries, but would it be possible for the authors of the two libraries to come up with a joint proposal? There may be room for two libraries if they are significantly different in some key aspect and both can be useful in different circumstances. If they are more or less the same, I agree only one should be accepted.
2024年7月28日(日) 19:17 Klemens Morgenstern via Boost <boost@lists.boost.org>:
On Sat, Jul 27, 2024 at 3:49 PM Takatoshi Kondo via Boost <boost@lists.boost.org> wrote:
Let me clarify the status of async_mqtt. I am ready for the formal review and I informed my review manager, Robert Ramey, on June 21st. As the author of one of the libraries, I will leave the management of the review process up to the review managers. I trust that the process will be conducted fairly.
Do you think fairness requires a simultaneous review with mireo/async_mqtt5 ? Or would a regular review of just your library suffice?
Robert is working on solving the issue, so I think that I should wait for his result. However, sharing my idea might help. Vinnie Falco wrote the following in this thread on May 21, 2024, at 12:28 AM:
However, upon discussions with high reputable sources (basically Peter Dimov), the criteria for "what belongs in Boost" is that "a library is useful." Applying this metric, I would think that if both MQTT libraries are useful then they should both be reviewed with the potential for acceptance.
I agree with this idea. Therefore, the possible outcomes are four combinations: both libraries accepted, one library accepted, or both libraries rejected. If the formal reviews are conducted separately, the first review's outcome shouldn't affect the second one. If this independence is guaranteed, I think it would be fair. Let me explain an unfair hypothetical scenario example: The first library is accepted, but the second one is rejected because "Boost already has that functionality." This would be unfair. --- Regards, Takatoshi Kondo
On Sun, Jul 28, 2024 at 4:57 PM Takatoshi Kondo via Boost < boost@lists.boost.org> wrote:
Let me explain an unfair hypothetical scenario example: The first library is accepted, but the second one is rejected because "Boost already has that functionality." This would be unfair.
We need to be careful here. Consider Boost.JSON. It implements a variant-like, mutable container which can hold a JSON document. Is there room for other JSON libraries in Boost? Why yes, there are. For example, SIMDJson uses a completely different approach. It is read-only and it makes a different set of tradeoffs. When I say that if both libraries are useful, they should both be considered for inclusion, we must carefully define "useful." If two libraries offer a set of features, or if the two libraries make different tradeoffs to the extent that such tradeoffs result in different and meaningful user bases, then both could be considered. On the other hand if both libraries offer the same set of features, and substantially similar tradeoffs (assuming of course that one library is not unreasonably slower than the other), the question of whether or not both are needed might need a different answer. Thanks
Vinnie Falco Sent Sunday, July 28, 2024 8:49 PM
We need to be careful here. Consider Boost.JSON. It implements a variant-like, mutable container which can hold a JSON document. Is there room for other JSON libraries in Boost? Why yes, there are. For example, SIMDJson uses a completely different approach. It is read-only and it makes a different set of tradeoffs.
When I say that if both libraries are useful, they should both be considered for inclusion, we must carefully define "useful." If two libraries offer a set of features, or if the two libraries make different tradeoffs to the extent that such tradeoffs result in different and meaningful user bases, then both could be considered.
Exactly right, witness Statechart and MetaStateMachine (MSM) with different design goals. This topic was much discussed during the MSM review, as author Cristophe Henry notes in the Stackoverflow link below. https://stackoverflow.com/questions/4275602/boost-statechart-vs-meta-state-m... ---------------------------------------------------------------------- This message, and any attachment(s), is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/electronic-disclaimer. If you are not the intended recipient, please delete this message. For more information about how Bank of America protects your privacy, including specific rights that may apply, please visit the following pages: https://business.bofa.com/en-us/content/global-privacy-notices.html (which includes global privacy notices) and https://www.bankofamerica.com/security-center/privacy-overview/ (which includes US State specific privacy notices such as the http://www.bankofamerica.com/ccpa-notice).
On 7/29/24 8:00 AM, Nelson, Erik - 2 via Boost wrote:
Exactly right, witness Statechart and MetaStateMachine (MSM) with different design goals. This topic was much discussed during the MSM review, as author Cristophe Henry notes in the Stackoverflow link below.
https://stackoverflow.com/questions/4275602/boost-statechart-vs-meta-state-m...
Thanks for tracking this down. This incident is the one that motivated me to express my concern about having multiple libraries which might or might not address the same problem. I'm trying to get a consensus about what's going to happen if two libraries are approved. I'd prefer to have the discussion a head of time rather than disputing it afterwards. On the other hand, maybe both libraries don't pass review in which case there's no problem. It would be a pity of the second library reviewed got no reviews because the first one had already been accepted. I don't have a strong opinion at this point about what our policy should be, but I do think we do need a policy. FWIW - one of the goals of the BoostLibraryIncubator was to permit the accumulation of reviews before the review period which might help resolve/address these concerns. Robert Ramey
On Tue, Jul 30, 2024 at 8:24 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
It would be a pity of the second library reviewed got no reviews because the first one had already been accepted.
How about this, people whose day of their birth is odd reviews the first library. And the others review the second. This happens concurrently. After that review is over (which will have mixed results) another review happens back to back, and everyone swaps libraries. Thanks
2024年7月31日(水) 1:29 Vinnie Falco via Boost <boost@lists.boost.org>:
On Tue, Jul 30, 2024 at 8:24 AM Robert Ramey via Boost <boost@lists.boost.org> wrote:
It would be a pity of the second library reviewed got no reviews because the first one had already been accepted.
How about this, people whose day of their birth is odd reviews the first library. And the others review the second. This happens concurrently. After that review is over (which will have mixed results) another review happens back to back, and everyone swaps libraries.
I think it is a nice and practical idea, if the reviewers are open to it.. Thanks, Takatoshi Kondo
On Sun, Jul 28, 2024, 6:57 PM Takatoshi Kondo via Boost < boost@lists.boost.org> wrote:
If the formal reviews are conducted separately, the first review's outcome shouldn't affect the second one. If this independence is guaranteed, I think it would be fair.
Let me explain an unfair hypothetical scenario example: The first library is accepted, but the second one is rejected because "Boost already has that functionality." This would be unfair.
It would be unfair. One solution would be for people to submit review votes privately. And having the results published only after both are reviewed.
Hello all, On 2024年7月28日(日) 19:17 Klemens Morgenstern via Boost <boost@lists.boost.org>:
However, upon discussions with high reputable sources (basically Peter Dimov), the criteria for "what belongs in Boost" is that "a library is useful."
I remember a discussion very similar about this about 15 years ago and IIRC, I was under the impression that usability would be the most important factor and so two competing libraries should be possible. However, that didn't seem to be the case at the time, with very respectable people from Boost not agreeing with me. It was a hypothetical case at the time, though. I'm still under the impression that multiple competing libraries should be acceptable if they scratch a different itch for different people. Kind regards, -- Felipe Magno de Almeida Owner @ Expertise Solutions www: https://expertise.dev phone: +55 48 9 9681.0157 LinkedIn: in/felipealmeida
A very understandable position. My concern was to avoid the possibility of having two similar and/or conflicting libraries which has happened before. How about relaying this discussion to the "Boost Review Wizard" who is the designated person for scheduling reviews.
According to the page https://www.boost.org/community/reviews.html#Wizard The role of Boost Review Wizard is currently played by: Mateusz Loskot (mateusz at loskot dot net) John Phillips (johnphillipsithaca at gmail dot com) I think the resolution of this situation falls to them. Could you gentlemen step in here? Robert Ramey
On Sat, May 18, 2024 at 11:27 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:
...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.
I have similar thoughts as you and until this year I had my own ideas about "what belongs in Boost." As there is no formal document or informal exposition offered by the Boost Libraries project website I evolved my own thinking as I am sure that others have done. However, upon discussions with high reputable sources (basically Peter Dimov), the criteria for "what belongs in Boost" is that "a library is useful." Applying this metric, I would think that if both MQTT libraries are useful then they should both be reviewed with the potential for acceptance. It really would be nice if there was some kind of documented rationale for what libraries belong in Boost as this would eliminate the speculation and guesswork. Thanks
On 5/20/24 8:28 AM, Vinnie Falco via Boost wrote:
On Sat, May 18, 2024 at 11:27 AM Robert Ramey via Boost < boost@lists.boost.org> wrote:
I have similar thoughts as you and until this year I had my own ideas about "what belongs in Boost." As there is no formal document or informal exposition offered by the Boost Libraries project website I evolved my own thinking as I am sure that others have done.
However, upon discussions with high reputable sources (basically Peter Dimov), the criteria for "what belongs in Boost" is that "a library is useful." Applying this metric, I would think that if both MQTT libraries are useful then they should both be reviewed with the potential for acceptance.
Since C++11 C++ standard committee accepted a large number of Boost libraries - thus fulfilling the original purpose of boost. The question then arose - what should Boost do now? Most successful organizations confront this problem. No one who has invested significant effort in the original organization wants to just wind it down. So the search for a new purpose is undertaken. In many cases, no such new purpose is found and the organization just withers into irrelevancy (even though as an organization it could linger on forever - at least until the money runs out). If it's a for profit organization, it's just killed off by lack of investors and customers. This is one of the signature benefits of Capitalism. Boost has been flailing around since that time looking for a new mission. I'd suggest a mission statement like: "The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard." I think much of the current infrastructure we have - review process etc. is well suited to the above stated purpose. I have a number of reservations about our development support aspects - website, build, documentation, etc. etc. which I've stated previously.
It really would be nice if there was some kind of documented rationale for what libraries belong in Boost as this would eliminate the speculation and guesswork.
Thanks
You're welcome. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
I'd suggest a mission statement like:
"The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard."
A lot of what I've been doing _can_ be standardized, even if most of it probably won't be. E.g. https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3171r0.html So I don't think we need to restrict Boost to things that aren't going to ever be standard.
On 5/20/24 11:24 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
I'd suggest a mission statement like:
"The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard."
A lot of what I've been doing _can_ be standardized, even if most of it probably won't be.
E.g. https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3171r0.html
So I don't think we need to restrict Boost to things that aren't going to ever be standard.
The closest I can find to a "Mission Statement" for Boost is on this page: https://www.boost.org "We emphasize libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages the use of Boost libraries for all users with minimal restrictions. We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Beginning with the ten Boost Libraries included in the Library Technical Report (TR1) and continuing with every release of the ISO standard for C++ since 2011, the C++ Standards Committee has continued to rely on Boost as a valuable source for additions to the Standard C++ Library." Which strongly suggests a strong focus on enhancements to the standard library. It's also way too wordy for a "Mission Statement". I think rewording this and have a discussion thereof would be helpful us find our bearings again. I've made my suggestion above, what would be yours? Robert Ramey
No dia 20 de mai. de 2024, às 20:24, Peter Dimov via Boost <boost@lists.boost.org> escreveu:
Robert Ramey wrote:
I'd suggest a mission statement like:
"The purpose of Boost is to encourage the development of useful quality C++ software not expected to be part of the C++ standard."
A lot of what I've been doing _can_ be standardized, even if most of it probably won't be.
E.g. https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2024/p3171r0.html
So I don't think we need to restrict Boost to things that aren't going to ever be standard.
FWIW, I expect to release this week a research/opinion article on these very issues of standardization, WG21 and Boost. Joaquín M López Muñoz
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.
Has Mireo agreed to license their library under the BSL? I asked on Slack a few weeks ago, but the repo is still showing only BSD-3-Clause. Matt
Yes, we'll change the library license to BSL after the review. We originally chose the BSD 3-Clause license to avoid giving the impression that the library was already part of Boost.
On 21.05.2024., at 10:25, Matt Borland via Boost <boost@lists.boost.org> wrote:
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.
Has Mireo agreed to license their library under the BSL? I asked on Slack a few weeks ago, but the repo is still showing only BSD-3-Clause.
Matt<publickey - matt@mattborland.com - 0xC1382EAD.asc> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ivica
Ivica Siladic wrote:
Yes, we'll change the library license to BSL after the review.
You need to change it before any review. We don't want to be in a position where the future licence depends on the outcome of the review.
We originally chose the BSD 3-Clause license to avoid giving the impression that the library was already part of Boost.
There is plenty of non-Boost code out there using the Boost licence - in the same way that there is plenty of non-BSD code using the BSD licence. Regards, Phil.
I only volunteered for the mireo library (i.e. the "other" one from your perspective). I don't think redboltz is ready for review so I don't want to be RM. Furthermore I fear I might be too biased between the two of the libraries to be review manager of both.
Hmm, a review manager admitting a strong bias for a potential library isn't a good look. To the point though, we should accept the protocol library one so it can be used for other networking implementations. Modern advancements can make implementations roughly 2x as fast as Asio. - Christian
On Tue, May 21, 2024 at 10:26 PM Christian Mazakas via Boost <boost@lists.boost.org> wrote:
I only volunteered for the mireo library (i.e. the "other" one from your perspective). I don't think redboltz is ready for review so I don't want to be RM. Furthermore I fear I might be too biased between the two of the libraries to be review manager of both.
Hmm, a review manager admitting a strong bias for a potential library isn't a good look.
Where did I use the word "strong" exactly? It's just a more complex decision that means it's harder to know and then purposely ignore one's own bias, because it's a single variable. With two libraries you end up with a more complex situation where the way you present the libraries or schedule the reviews might advantage one over the other. And that can be subconscious, e.g. when announcing the review I might put some emphasis on a certain feature or deficiency of one library might influence reviewers a certain way. That's hard to account for, whereas a review decision that disagrees with my own opinion is pretty easy to reach and I have in the past. But I don't think it's a good idea to have a single review manager for two libraries in a competitive review with unclear rules. Maybe one of the review wizards and provide some wisdom on how this might work?
To the point though, we should accept the protocol library one so it can be used for other networking implementations. Modern advancements can make implementations roughly 2x as fast as Asio.
Well redboltz isn't a pure protocol library in that sense either, it's just lower level than mireos. It's still very much married to asio. It's akin to beast being on the protocol level, while a library like python-requests is a simpler client. To the point though, "we should accept" is not a thing to be discussed while scheduling a review, but during review.
- Christian
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, May 21, 2024 at 7:26 AM Christian Mazakas via Boost < boost@lists.boost.org> wrote:
we should accept the protocol library one
Neither of the two proposed libraries are "sans-io." That is, they both contain algorithms which invoke Boost.Asio in their implementations. Thanks
participants (16)
-
Andrey Semashev -
Christian Mazakas -
Felipe Magno de Almeida -
Georg Gast -
Ivica Siladic -
Joaquín M López Muñoz -
Klemens Morgenstern -
Matt Borland -
Nelson, Erik - 2 -
Peter Dimov -
Phil Endecott -
René Ferdinand Rivera Morell -
Robert Ramey -
Ruben Perez -
Takatoshi Kondo -
Vinnie Falco