I would like to thank Vinnie Falco and Krystian Stasiowski for developing this library and bringing it to the boost. I will try to keep the mail short and point to point. ---- RESULT ---- Boost.JSON is ACCEPTED into the Boost. Now the process to transition repository to boost can start and get this library published in next release according to the guidelines. There was some heat around the discussion, I would like to clarify that this is not a completely democratic decision. Though there are more accept votes but I was a bit leaned toward the arguments made in the favour of reject as those arguments were analysed thoroughly and on point and I agreed with them. On the other hand, considering the targeted audience and the goal of the library those arguments are weighed less in my opinion. "Can't reject an Apple because it is not an Orange". In general, the library looks great to me and I am sure it will attract new users too because it has good documentation, friendly APIs and design and good performance too. ---- REVIEWS ---- There was a good amount of discussion and definitely more reviews than I expected including a few first-time reviewers. Summary: Accept: 14 Reject: 3 Conditional accept: 1 Some positive reviews: It is very good, and meets the highest Boost standards. I mean both the
tutorial and reference sections. While doing this review I had to look at the documentation of the competing libraries, and they are really bad. This is why I can appreciate the big effort you put in making these docs. There is a section "Comparison" that compares Boost.JSON to other JSON libraries. I personally think it should also mention the documentation.
The design takes some time to get used to, but it fits well to the
problem being tackled (a JSON-DOM library). Switching my codebases using RapidJSON to this library made the code more readable and it will also allow me to get rid of a significant amount of boilerplate.
The fact that this value type has been highly optimized is the great
strength of this library.
Design is very good. The parser interfaces and object building interfaces
meet my needs. I especially want to call out the pmr support and it's support for either sharing or transferring ownership of resources.
Some critical reviews: Binary size matters a lot, since onboard Flash is very limited. I am
using a "big" MCU, and that means my whole binary must be under ~512 KB. Right now Boost JSON is not great. In doing a simple serialization and parse, the library itself adds ~58 KB to my .text section. This is OK for now, but surprisingly big. I know the team is aware of this and has some ideas to reduce the binary size. I will likely need those fixes to actually port my app to Boost JSON.
It would be better for the library to just template on allocator just like
the vector class in the C++ standard
...and many more positive and critical reviews... A Thing I was explicitly asked to note:
The memory management model is extremely simple. I wonder if storage_ptr could be moved somewhere else long term so other libraries can use it.
I think that's it. I would like to thank everyone who was involved in the review process every review was important and gives new insight and helps to make boost better. Best of luck to the authors and the maintainers of the library. -- Thank you, Pranam Lashkari, https://lpranam.github.io/
Pranam Lashkari, Thanks for stepping up to be a review manager. It seems you've got a good grasp of the Boost culture. I'm sure that managing the review turned out to be a lot more than you bargained for. Still, you buckled down and got the job done in a timely fashion. Your summary was succinct as well. I hope your experience - along with this note - will encourage more new participants of boost at this level. On a related note, I know that these reviews and the review summary are stored "permanently" "somewhere". I would like to see our boost library page include a pointer to these chains of posts. Ready access to this "historical" data would be very helpful to me as a potential user when I evaluate competing solutions to a problem that I might be having. Robert Ramey
-----Original Message----- From: Boost
On Behalf Of Robert Ramey via Boost Sent: 3 October 2020 20:52 To: boost@lists.boost.org Cc: Robert Ramey Subject: Re: [boost] [JSON][review] Result Pranam Lashkari,
Thanks for stepping up to be a review manager. It seems you've got a good grasp of the Boost culture. I'm sure that managing the review turned out to be a lot more than you bargained for. Still, you buckled down and got the job done in a timely fashion. Your summary was succinct as well. I hope your experience - along with this note - will encourage more new participants of boost at this level.
On a related note, I know that these reviews and the review summary are stored "permanently" "somewhere". I would like to see our boost library page include a pointer to these chains of posts. Ready access to this "historical" data would be very helpful to me as a potential user when I evaluate competing solutions to a problem that I might be having.
This would be a really good idea. Perhaps a simple link to the review on Nabble etc in the documentation's history section (I hope there will be one) would meet this need? Paul
On Sat, 3 Oct 2020 at 21:51, Robert Ramey via Boost
On a related note, I know that these reviews and the review summary are stored "permanently" "somewhere". I would like to see our boost library page include a pointer to these chains of posts.
The reviews schedule [1] includes some chronological pointers. I'm not sure what else you'd like to see. https://www.boost.org/community/review_schedule.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Words of appreciation mean a lot to me. Because I started my journey with
boost watching your videos on youtube :)
On Sun, Oct 4, 2020 at 1:21 AM Robert Ramey via Boost
Pranam Lashkari,
Thanks for stepping up to be a review manager. It seems you've got a good grasp of the Boost culture. I'm sure that managing the review turned out to be a lot more than you bargained for. Still, you buckled down and got the job done in a timely fashion. Your summary was succinct as well. I hope your experience - along with this note - will encourage more new participants of boost at this level.
Words of appreciation from you mean a lot to me. Because I started my journey with boost watching your videos on youtube :) Yes, I have had good mentors to guide me about boost and boost culture(Vinícius dos Santos Oliveira and Mateusz Loskot) to whom I am very thankful. On a related note, I know that these reviews and the review summary are
stored "permanently" "somewhere". I would like to see our boost library page include a pointer to these chains of posts. Ready access to this "historical" data would be very helpful to me as a potential user when I evaluate competing solutions to a problem that I might be having.
As Mateusz pointed we have some pointers on the review page[1]. [1]: https://www.boost.org/community/review_schedule.html -- Thank you, Pranam Lashkari, https://lpranam.github.io/
On 10/5/20 3:28 AM, Pranam Lashkari via Boost wrote:
On a related note, I know that these reviews and the review summary are
stored "permanently" "somewhere". I would like to see our boost library page include a pointer to these chains of posts. Ready access to this "historical" data would be very helpful to me as a potential user when I evaluate competing solutions to a problem that I might be having.
As Mateusz pointed we have some pointers on the review page[1].
This is not enough for me. I want links to the email chains on the news feed. I also want link to the review results / commentary. Robert Ramey
On Mon, 5 Oct 2020 at 18:55, Robert Ramey via Boost
On 10/5/20 3:28 AM, Pranam Lashkari via Boost wrote:
On a related note, I know that these reviews and the review summary are
stored "permanently" "somewhere". I would like to see our boost library page include a pointer to these chains of posts. Ready access to this "historical" data would be very helpful to me as a potential user when I evaluate competing solutions to a problem that I might be having.
As Mateusz pointed we have some pointers on the review page[1].
This is not enough for me.
I want links to the email chains on the news feed.
TBH, I can't see it feasible to maintain lists of posts/threads. I see dates in the table. I go to https://lists.boost.org/Archives/boost/2020/09/ I find relevant period/month and I get list of threads/links in neat chronological form presented: https://lists.boost.org/Archives/boost/2020/09/ The only issue is to ask reviewers to use good subjects, e.g. [library][review] My Review
I also want link to the review results / commentary.
Link to review results announcement is there, click to it and access the follow-up posts. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
pon., 5 paź 2020 o 19:12 Mateusz Loskot via Boost
On 10/5/20 3:28 AM, Pranam Lashkari via Boost wrote:
On a related note, I know that these reviews and the review summary are
stored "permanently" "somewhere". I would like to see our boost
On Mon, 5 Oct 2020 at 18:55, Robert Ramey via Boost
wrote: library page include a pointer to these chains of posts. Ready access to this "historical" data would be very helpful to me as a potential user when I evaluate competing solutions to a problem that I might be having.
As Mateusz pointed we have some pointers on the review page[1].
This is not enough for me.
I want links to the email chains on the news feed.
TBH, I can't see it feasible to maintain lists of posts/threads.
I see dates in the table. I go to https://lists.boost.org/Archives/boost/2020/09/ I find relevant period/month and I get list of threads/links in neat chronological form presented: https://lists.boost.org/Archives/boost/2020/09/
The only issue is to ask reviewers to use good subjects, e.g. [library][review] My Review
I also want link to the review results / commentary.
Link to review results announcement is there, click to it and access the follow-up posts.
As an alternative to all this, one could expect a library author to compile a summary of the issues and controversies brought during the review (at least the most interesting/relevant ones) and put it in the docs under section "Design Discussion". But I am not sure if this would be polite to actually expect that from the authors. They are already putting enormous effort and offer their free time to design and document the library, and undergo the difficult process of Boost Review. Some libraries do that, though. Regards, &rzej;
On Mon, Oct 5, 2020 at 10:22 AM Andrzej Krzemienski via Boost
As an alternative to all this, one could expect a library author to compile a summary of the issues and controversies brought during the review (at least the most interesting/relevant ones) and put it in the docs under section "Design Discussion".
I would love to do this but as you pointed out it is a lot of work and usually I am struggling just to keep up with the regular work of documentation and library maintenance, with no bandwidth available for the luxury of journaling my design thoughts and other people's feedback!! Thanks
On Mon, Oct 5, 2020 at 10:12 AM Mateusz Loskot via Boost
TBH, I can't see it feasible to maintain lists of posts/threads.
That is because you lack imagination. boost.org should have its own forum, instead of mailing lists. And when there is a formal review, the wizards create a subforum specifically for the review. Thus all posts and discussion relevant to the review will be categorized / organized into one subforum which after 3 months is then moved from "Recent Reviews" to "Archived Reviews" where they become available and viewable in perpetuity. Thanks
On Mon, 5 Oct 2020 at 19:22, Vinnie Falco
On Mon, Oct 5, 2020 at 10:12 AM Mateusz Loskot via Boost
wrote: TBH, I can't see it feasible to maintain lists of posts/threads.
That is because you lack imagination.
In this particular case, it's about lack of time to maintain such lists.
boost.org should have its own forum, instead of mailing lists. And when there is a formal review, the wizards create a subforum specifically for the review. Thus all posts and discussion relevant to the review will be categorized / organized into one subforum which after 3 months is then moved from "Recent Reviews" to "Archived Reviews" where they become available and viewable in perpetuity.
We have been incapable of pushing the idea of paying for CI services forward for year+, where money is no issue, I hear, that would impose zero maintenance cost on Boost folks. And, you are proposing to set up a new piece of infrastructure, with accounts, security, that will also require moderation, etc. Although I really like the idea, I can't see it feasible. The mailman offers very usable access interfaces to all the archived reviews and related (public) discussions, it just takes time and clicking. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Oct 5, 2020, at 1:38 PM, Mateusz Loskot via Boost
wrote: boost.org should have its own forum, instead of mailing lists. And when there is a formal review, the wizards create a subforum specifically for the review. Thus all posts and discussion relevant to the review will be categorized / organized into one subforum which after 3 months is then moved from "Recent Reviews" to "Archived Reviews" where they become available and viewable in perpetuity.
We have been incapable of pushing the idea of paying for CI services forward for year+, where money is no issue, I hear, that would impose zero maintenance cost on Boost folks. And, you are proposing to set up a new piece of infrastructure, with accounts, security, that will also require moderation, etc. Although I really like the idea, I can't see it feasible.
Just thinking out of the box, and this may be a horrible idea, but… what if you created a new `boostorg-proposed` account on GitHub, where every proposed library gets moved into as a separate repo, before their review starts. Then each individual review can be a GitHub issue for that, and comments to each review can be comments inside that review-issue. People can then subscribe or not to the specific proposal repos for issues and changes. And the reviews and their comments live in perpetuity (or as long as GitHub does I suppose). If the proposal is accepted, then the repo is copied/cloned into `boostorg` as it is today, and a link is added to the readme.md pointing to that library's proposal repo for finding reviews and their comments. The “infrastructure” aspect is then already in-place. -hadriel
On Mon, Oct 5, 2020 at 11:29 PM Hadriel Kaplan via Boost < boost@lists.boost.org> wrote:
Just thinking out of the box, and this may be a horrible idea, but… what if you created a new `boostorg-proposed` account on GitHub, where every proposed library gets moved into as a separate repo, before their review starts.
Then each individual review can be a GitHub issue for that, and comments to each review can be comments inside that review-issue.
People can then subscribe or not to the specific proposal repos for issues and changes.
And the reviews and their comments live in perpetuity (or as long as GitHub does I suppose).
If the proposal is accepted, then the repo is copied/cloned into `boostorg` as it is today, and a link is added to the readme.md pointing to that library's proposal repo for finding reviews and their comments.
The “infrastructure” aspect is then already in-place.
This makes sense to me if we are trying to avoid new infrastructure this can be the best idea, easy to maintain easy to search and everything at a place... -- Thank you, Pranam Lashkari, https://lpranam.github.io/
On Mon, 5 Oct 2020 at 19:58, Hadriel Kaplan
On Oct 5, 2020, at 1:38 PM, Mateusz Loskot via Boost
wrote: boost.org should have its own forum, instead of mailing lists. And when there is a formal review, the wizards create a subforum specifically for the review. Thus all posts and discussion relevant to the review will be categorized / organized into one subforum which after 3 months is then moved from "Recent Reviews" to "Archived Reviews" where they become available and viewable in perpetuity.
We have been incapable of pushing the idea of paying for CI services forward for year+, where money is no issue, I hear, that would impose zero maintenance cost on Boost folks. And, you are proposing to set up a new piece of infrastructure, with accounts, security, that will also require moderation, etc. Although I really like the idea, I can't see it feasible.
Just thinking out of the box, and this may be a horrible idea, but… what if you created a new `boostorg-proposed` account on GitHub, where every proposed library gets moved into as a separate repo, before their review starts.
Then each individual review can be a GitHub issue for that, and comments to each review can be comments inside that review-issue.
People can then subscribe or not to the specific proposal repos for issues and changes.
And the reviews and their comments live in perpetuity (or as long as GitHub does I suppose).
If the proposal is accepted, then the repo is copied/cloned into `boostorg` as it is today, and a link is added to the readme.md pointing to that library's proposal repo for finding reviews and their comments.
The “infrastructure” aspect is then already in-place.
I'll leave it to Robert Ramey to comment if that would solve the issues he pointed out. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 10/5/20 11:41 AM, Mateusz Loskot via Boost wrote:
On Mon, 5 Oct 2020 at 19:58, Hadriel Kaplan
wrote: On Oct 5, 2020, at 1:38 PM, Mateusz Loskot via Boost
wrote: boost.org should have its own forum, instead of mailing lists. And when there is a formal review, the wizards create a subforum specifically for the review. Thus all posts and discussion relevant to the review will be categorized / organized into one subforum which after 3 months is then moved from "Recent Reviews" to "Archived Reviews" where they become available and viewable in perpetuity.
We have been incapable of pushing the idea of paying for CI services forward for year+, where money is no issue, I hear, that would impose zero maintenance cost on Boost folks. And, you are proposing to set up a new piece of infrastructure, with accounts, security, that will also require moderation, etc. Although I really like the idea, I can't see it feasible.
Just thinking out of the box, and this may be a horrible idea, but… what if you created a new `boostorg-proposed` account on GitHub, where every proposed library gets moved into as a separate repo, before their review starts.
Then each individual review can be a GitHub issue for that, and comments to each review can be comments inside that review-issue.
People can then subscribe or not to the specific proposal repos for issues and changes.
And the reviews and their comments live in perpetuity (or as long as GitHub does I suppose).
If the proposal is accepted, then the repo is copied/cloned into `boostorg` as it is today, and a link is added to the readme.md pointing to that library's proposal repo for finding reviews and their comments.
The “infrastructure” aspect is then already in-place.
I'll leave it to Robert Ramey to comment if that would solve the issues he pointed out.
I noted the boost library incubator had this facility. But the whole thing could be simplified by using a lot of the functionality of github. It's also possible that reviews and results could be posted as issues to the library in github. This would give the result of maintaining review history which started this thread in the first place. In general, the boost library incubator could be streamlined and simplified if someone wanted to do that. Robert Ramey
On 10/5/20 10:22 AM, Vinnie Falco via Boost wrote:
On Mon, Oct 5, 2020 at 10:12 AM Mateusz Loskot via Boost
wrote: TBH, I can't see it feasible to maintain lists of posts/threads.
That is because you lack imagination.
boost.org should have its own forum, instead of mailing lists. And when there is a formal review, the wizards create a subforum specifically for the review. Thus all posts and discussion relevant to the review will be categorized / organized into one subforum which after 3 months is then moved from "Recent Reviews" to "Archived Reviews" where they become available and viewable in perpetuity.
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Actually, the Boost Library Incubator (www.blincubator.com) contains exactly this facility. I made it some 5 years ago to support the review process and to help library authors prepare their libraries for review. I made it in word press because it seemed the easiest and I wanted to learn more about web application development. a) I was more or less happy with the result. b) I found web development/tedious activity and couldn't really get motivated to spend more time on it. c) It originally has some issues with wordpress security - but those all got addressed by upgrading to a better web provider. d) I had decided to depend on wordpress components. This is in line with the boost philosophy of "why make your when there's already a better library". In general this was a good decision. e) There are any number of word press components available. They are easy to insert in to your application and easy to remove. BUT - most of them are not really ready for prime time and it takes a lot of effort to select, experiment with and validate components. I believe my average was to get a pre-made component for one function, I had to test 5 components and reject 4. Still better than doing everything from scratch - but still a pain. And if I have to reject four - how do I know that the one I selected doesn't have any hidden quirks. f) debugging was a big job. I found it very difficult to set up a test website without creating some weird side effects. Then one needs a system for setting up a "dynamic" path name. Probably could have found it eventually ... but I'm not known for my patience. g) Sooooo ... as a prototype www.blincubator.com was helpful. But as a real solution, it would require more commitment than I could muster. h) programming in PHP is ... terrible. It's like perl. Its one hack after another. Debugging is even worse. Probably there's a fix for all of this, but would require investment of a lot more effort than I was willing to make. I did learn alot though - the main thing is that I want to stay away from web development which is basically a hack patching another hack invoked as a component of another hack. It's basically hacks all the way down! Robert Ramey
On Sat, Oct 3, 2020 at 11:54 AM Pranam Lashkari
Boost.JSON is ACCEPTED into the Boost. Now the process to transition repository to boost can start and get this library published in next release according to the guidelines.
Thank you Pranam for the time you invested into acting as review manager. I know it is a lot of work. To all who reviewed the library (including those who rejected it), thank you for taking the time to look at this work. I am head-down now fervently addressing all of the issues that were raised during review. I am targeting the next Boost release for inclusion of Boost.JSON. If you would like to participate, feel free to kick the tires but most importantly use GitHub Issues to point out bugs or request features, as I am using that for guidance on what to do for release. Regards
On Sat, 3 Oct 2020 at 20:54, Pranam Lashkari
I would like to thank Vinnie Falco and Krystian Stasiowski for developing this library and bringing it to the boost.
I will try to keep the mail short and point to point.
---- RESULT ---- Boost.JSON is ACCEPTED into the Boost.
Well done Pranam and thank you very much for your efforts. Congratulations to authors of the Boost.JSON! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
participants (7)
-
Andrzej Krzemienski
-
Hadriel Kaplan
-
Mateusz Loskot
-
pbristow@hetp.u-net.com
-
Pranam Lashkari
-
Robert Ramey
-
Vinnie Falco