We are proud to publish the first Boost Release Report, for 1.87.0. This report is designed to showcase and credit the work of the many volunteers who contribute to the libraries and other things in Boost, published as an official release three times a year. https://downloads.cppalliance.org/reports/boost_1_87_0_release_report.pdf Thanks
On Sat, Dec 14, 2024 at 6:13 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:
We are proud to publish the first Boost Release Report, for 1.87.0. This report is designed to showcase and credit the work of the many volunteers who contribute to the libraries and other things in Boost, published as an official release three times a year.
https://downloads.cppalliance.org/reports/boost_1_87_0_release_report.pdf
I appreciate the effort, but the stats feel a bit like counting productivity in terms of LOC. Neither the amount of commits nor posts tell me anything about their content. That is, the first two pages would suffice. What are you trying to communicate with pages 3-98? If you want to write a release report, I think it should not be auto-generated (except for maybe the first page), but editorialized highlights. E.g. it could summarize the review of a library and the library in the release (boost parser in this case). Or, even better, it could put a spotlight on recent improvements/changes in a library, e.g. I could help write something when asio has some major additions.
Thanks
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Dec 13, 2024 at 11:55 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:
If you want to write a release report, I think it should not be auto-generated
Feel free to write your own release report, containing (or not containing) the elements of your choice. Thanks
On 13/12/2024 22:13, Vinnie Falco via Boost wrote:
We are proud to publish the first Boost Release Report, for 1.87.0. This report is designed to showcase and credit the work of the many volunteers who contribute to the libraries and other things in Boost, published as an official release three times a year.
https://downloads.cppalliance.org/reports/boost_1_87_0_release_report.pdf
This is interesting... somewhat, but I'm not sure how useful it is at present, or how well it reflects the overall "health" of your favorite library. Something that might be useful to see, would be two lists: one of libraries with no commits, and one with no issues fixed. That might help focus minds on which libraries need community assistance, and which should quite frankly be deprecated. I notice that some of the libraries listed only have "infrastructure" commits which would also count as "no real maintenance". BTW if this is intended for end users, then I think something closer to a "press release" - with all the work entailed in writing that - would be much more appropriate. Please do keep experimenting with this though. Best, John.
On Tue, Dec 17, 2024 at 6:06 AM John Maddock via Boost < boost@lists.boost.org> wrote:
This is interesting... somewhat, but I'm not sure how useful it is at present, or how well it reflects the overall "health" of your favorite library.
Thanks for the feedback. The release report is aimed at contributors, not end users. This is a little something to help recognition of effort. For end users we put this information directly on the website itself. For example, Boost.Math shows everyone who contributed to the last release and they are sorted descending by the number of commits: https://www.boost.io/library/1.87.0/math/ The "health" of libraries should be reflected on the website since that will affect the new or returning user experience. I'm not sure how we want to reflect it so some experimentation is probably needed. The release report is pretty rough since it is the first version and we will continue to iterate on it. Something that might be useful to see, would be two lists: one of
libraries with no commits, and one with no issues fixed. That might help focus minds on which libraries need community assistance, and which should quite frankly be deprecated. I notice that some of the libraries listed only have "infrastructure" commits which would also count as "no real maintenance".
There are a couple of ways to go about this. One is that we can do some elaborate analysis of the repositories. On the other hand, there are only a finite number of repos. We could just manually mark the ones we believe should be "deprecated." I brought up the idea of deprecating libraries and there was a lot of opposition. So deprecation per-se might not be the right path. Instead we could just mark the libraries on the site and provide some sorting options. I'm happy to hear ideas on what to do.
BTW if this is intended for end users, then I think something closer to a "press release" - with all the work entailed in writing that - would be much more appropriate.
It is really just for contributors. They deserve something special. There's a place for the FSC to communicate on every release. I'm hoping that as we iterate on this it becomes more valuable and useful for bringing the volunteers together, building a sense of pride and accomplishment, and general good feels. Thanks
On 12/17/24 17:31, Vinnie Falco via Boost wrote:
On Tue, Dec 17, 2024 at 6:06 AM John Maddock via Boost < boost@lists.boost.org> wrote:
This is interesting... somewhat, but I'm not sure how useful it is at present, or how well it reflects the overall "health" of your favorite library.
Thanks for the feedback. The release report is aimed at contributors, not end users. This is a little something to help recognition of effort. For end users we put this information directly on the website itself. For example, Boost.Math shows everyone who contributed to the last release and they are sorted descending by the number of commits: https://www.boost.io/library/1.87.0/math/
Something seems off with that list: https://www.boost.io/library/1.87.0/filesystem/ I'm pretty sure Beman didn't commit anything for the 1.87.0 release: https://github.com/boostorg/filesystem/compare/boost-1.86.0...boost-1.87.0
On Tue, Dec 17, 2024 at 7:28 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
https://www.boost.io/library/1.87.0/filesystem/ I'm pretty sure Beman didn't commit anything for the 1.87.0 release:
Contributors who are listed in the meta/libraries.json files as authors or contributors always appear in the list, and they are sorted at the top in the order of: Authors, Maintainers. Happy to hear suggestions on how we might improve this for those who are no longer with us. Thanks
On 12/17/24 19:00, Vinnie Falco wrote:
On Tue, Dec 17, 2024 at 7:28 AM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
https://www.boost.io/library/1.87.0/filesystem/ <https:// www.boost.io/library/1.87.0/filesystem/> I'm pretty sure Beman didn't commit anything for the 1.87.0 release:
Contributors who are listed in the meta/libraries.json files as authors or contributors always appear in the list, and they are sorted at the top in the order of: Authors, Maintainers.
Happy to hear suggestions on how we might improve this for those who are no longer with us.
I think only those who actually contributed to the release should be listed in the "This Release" tile. Also, this whole tile should probably be moved lower, just above the "All Time" tile. This should group the contributors together and bring the library description up higher, which is more important to users. If you want to acknowledge the original authors, please list them elsewhere. For example, just mark the authors as "Author" in the "All Time" tile below, similar to how they are marked now in "This Release".
On 12/17/24 17:31, Vinnie Falco via Boost wrote:
On Tue, Dec 17, 2024 at 6:06 AM John Maddock via Boost < boost@lists.boost.org> wrote:
The "health" of libraries should be reflected on the website since that will affect the new or returning user experience. I'm not sure how we want to reflect it so some experimentation is probably needed. The release report is pretty rough since it is the first version and we will continue to iterate on it.
The usual practice to indicate activity in a project is to post stats for a release in the form of "X lines added, Y lines removed". This form is more relevant than the number of commits as it better correlates with the amount of changes. That said, "no changes" does not mean "dead project", so I'm not sure what should be inferred from these stats. IMO, they can only serve to satisfy curiosity. It would be a disservice to libraries if the users take these stats more seriously than this.
participants (4)
-
Andrey Semashev -
John Maddock -
Klemens Morgenstern -
Vinnie Falco