- Boost - lists.boost.org

Re: [boost] Boost Asset Stewardship Review begins 09/03 (Updated)
by Glen Fernandes 07 Sep '24

07 Sep '24

On Fri, Sep 6, 2024 at 7:44 PM Ion Gaztañaga wrote: > A: Yes, I think C++ Alliance’s proposal should be accepted, with a few > suggestions: Ion, a great many thanks for your review and the sentiments expressed within. Everyone, Ion's review didn't make it to the developer list because of an error in the address. I will ask him to repost it when he can tomorrow morning. Glen

1 0

Asset Stewardship Review
by M P 07 Sep '24

07 Sep '24

Here is my review of the proposed Boost.AssetStewardsipReview ## What is your evaluation of the design? The C++ Alliance has laid out a solid plan for boosting Boost, covering everything from revamping the website to improving integration, documentation, and library support. They’ve clearly identified the main issues and have offered practical, detailed solutions. They’re big on involving the Boost community and stakeholders, encouraging feedback and participation, and valuing everyone’s input. The Alliance is upfront about potential challenges like delays and costs, but they address these issues realistically. They’re not just offering quick fixes but are investing in new tools and dedicated staff for long-term support. On the flip side, the Boost Foundation’s concerns about the Alliance’s transparency and use of paid contributions might come across as overly critical. Sticking to slow decision-making and rigid governance could be seen as a barrier to innovation. Their focus on a purely volunteer-based setup might limit growth, and their critique of gender representation doesn't offer clear solutions. Some of their proposals, like improving mailing list behavior and adopting new tools, are a bit vague and might not be enough to attract fresh contributors or more dynamic approaches. ## What is your evaluation of the implementation? The implementation outlined in the text is well-organized and covers all the essential bases for Boost's long-term success. The C++ Alliance has already proven its value by setting up crucial infrastructure, like continuous integration and IT support, and by contributing to various libraries. The new Boost website is fantastic! Its modern design and user-friendly layout make it easy to navigate and find what you're looking for. With its fresh look and improved functionality, it's sure to catch the eye of new users and make their first experience with Boost a great one. Whether you're a seasoned developer or just getting started, the site’s clean interface and accessible resources are a huge plus. Their plan to revamp Boost’s brand and enhance its visibility is forward-thinking and aligns with what the community needs. The proposal to have the Alliance take on fiscal sponsorship aims to streamline operations and ensure financial stability. One thing to keep in mind is that the Alliance proposal comes with a legal agreement where a Steering Committee, made up entirely of Boost authors, gets to make decisions about the shared resources. If they're not happy with how things are going, they have the power to move those resources elsewhere. This kind of setup isn't mentioned in the Foundation proposal. So, while the idea of the Alliance handling fiscal sponsorship could definitely streamline operations and boost financial stability, how it plays out will depend on how well the Alliance and Boost community work together. ## What is your evaluation of the documentation? The C++ Alliance proposal is easy to follow and straightforward, clearly showcasing its contributions to Boost and laying out plans for future growth. It does a great job of explaining the benefits of the proposed governance changes and shows a real commitment to being open, sustainable, and collaborative. ## How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have dedicated considerable time to studying the proposals and related documents, and I have been aware of the ongoing conflict for some time. ## Are you knowledgeable about the problem domain? To some extent. With Boost's popularity declining in recent years, it's at a critical crossroads, and its future success may very well hinge on this decision. ## Do you think the C++ Alliance proposal should be accepted? Yes Miguel Portilla

2 1

Asset Stewardship Review
by Christian Mazakas 06 Sep '24

06 Sep '24

Disclaimer: Alliance employee Hi, I'm a little confused at what the Boost Foundation put forth. The opening review email states: > To be clear, the review is not about deciding governance over Boost > C++ library development. That remains in the hands of the Boost > developer community. But TBF's proposal seems entirely to be governance-related. In terms of asset stewardship, it's kind of a no-brainer to choose the organization that _didn't_ almost lose the boost.org domain name. Plus, the Alliance has Sam Darwin and he's infallible. But to the Boost Foundation's credit, I found myself agreeing with a lot of the points being mentioned. Boost _should_ consider introducing a formal CoC. Boost _should_ officially migrate to CMake and being direct here: this does mean completely abandoning b2. We need to revitalize Boost with the youth culture and to the youth, these things matter quite a bit. - Christian

9 20

Boost Asset Stewardship Review from Nick Thomson
by Glen Fernandes 06 Sep '24

06 Sep '24

Nick sent the following review to me at glenfe -at- boost.org. > From: Nick Thompson > Date: On Wed, Sep 4, 2024 at 18:26 > Subject: Fw: Boost Asset Stewardship Review > To: Glen Fernandes > > Vote: Transfer Boost Assets to the C++ Alliance > > Association with library: Contributor to math, multiprecision, > integer, random, and circular_buffer. Main contributions include > black box optimization, quadrature, and statistics in Boost.Math. > > Rationale: > > My contributions to Boost have mainly been implementation of > numerical algorithms. With each of these additions, years of future > maintenance work is implied. Even with the heroic efforts of John > Maddock, without the financial support of the C++ Alliance, these > libraries would accumulate so many open tickets that our reputation > would be badly damaged. Moreover, the utility of these libraries > would be greatly reduced. For example, there would be no way we could > support scipy's effort to expose Boost.Math to python-probably one of > the most impactful uses of Boost to date. The risk of the project > becoming completely defunk or slowly drifting into irrelevance > without continued financial support is extremely high. So as long as > the C++ Alliance is funding the maintenance, they should have the > most say in the continued operation of the library. > > Nick Thompson Nick, thank you for contributing a review. - Glen

2 1

Boost Asset Stewardship Review begins 09/03
by Glen Fernandes 05 Sep '24

05 Sep '24

Everyone, The formal review for the stewardship of Boost assets begins next week, September 3rd. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The C++ Alliance submitted the following proposal: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf Also attached to this email as: CplusplusAllianceFiscalSponsorshipProposal.pdf The Boost Foundation has prepared a proposal for the community's consideration that is waiting on review from all board members and will be posted before the end of day tomorrow (08/30, by 5pm EST). A follow up email will be posted when it is available so that it has visibility on the Boost developers list and the Announcement list. The review, like our C++ library formal reviews, is open to everyone to participate. The official review start announcement email next week will detail the process for participation. Thank you, - Glen

5 8

[iostreams] Custom allocator support for compression filters
by Daniel Boehme 04 Sep '24

04 Sep '24

Hello everyone, I'm currently looking into custom allocators with the boost::iostreams::gzip_compressor and now need some help understanding why the code is the way it is. My problem is that I need to control how zlib internally de-/allocates memory. It seems to have support for using custom de-/allocation functions. And iostreams seems to have used it some time ago. However, passing the custom allocator to zlib has been disabled in this commit: https://github.com/boostorg/iostreams/commit/95baf782098f0dee00cc7ca6f62b9b… Does anyone happen to know what has been non-conforming and why it was disabled? I could not find any information about that in the code, on the mailing lists, or anywhere else in the internet. I'm tempted to submit a patch that enables it, but for that I need to understand the reasons behind that deliberate decision. Any hint is welcome. Thank you very much. Daniel B?hme

2 1

[boost.cobalt] Cobalt not building with b2 on Windows
by Andreas Weis 02 Sep '24

02 Sep '24

Hi everyone, It's my understanding that Cobalt is *not* a header-only library, yet it seems that it is not built as part of the b2 build. I'm building Boost with b2 on Windows (MSVC 2022, version 19.41) and it seems that Cobalt is not being built properly. I am using the following command line: b2 --toolset=msvc-14.3 --build-type=complete architecture=x86 address-model=64 --stagedir=stage -j 8 As far as I can tell, this works correctly for all libraries except Cobalt. While b2 does list cobalt as part of the "Component configuration" listing in the output: - atomic : building - charconv : building - chrono : building - cobalt : building [...] But I get neither binaries nor a folder cmake/boost_cobalt* with this. It also seems that the Cobalt binaries are not part of the distribution at https://sourceforge.net/projects/boost/files/boost-binaries/. Am I doing something wrong? Is Cobalt supposed to be part of the b2 build or is there another way to consume the non-header-only parts of the library? Best regards, Andreas

3 3

Boost.Compute broken in 1.86.0 because of UUID changes, 1.86.1?
by Peter Dimov 30 Aug '24

30 Aug '24

Because Boost.Compute (boost/compute/detail/sha1.hpp) uses an implementation detail of Boost.UUID (boost/uuid/detail/sha1.hpp), and because I changed the implementation to fix an endianness issue, <boost/compute.hpp> now causes a compile error in 1.86.0, as reported in https://github.com/boostorg/uuid/issues/166 https://github.com/boostorg/compute/pull/887 https://github.com/boostorg/compute/pull/888 https://github.com/boostorg/compute/issues/889 Users are demanding we issue a point release to fix this. It will have to include https://github.com/boostorg/compute/pull/887 and https://github.com/boostorg/compute/pull/893 What do release managers think?

10 14

Inter pod communication using shared memory
by Murali Bathina 30 Aug '24

30 Aug '24

Hi all, Is Boost supports inter pod communication using shared memory or other ways like boost interprocess communication. Looking inputs on this. Regards, Murali ________________________________ This e-mail message may contain confidential or proprietary information of Mavenir Systems, Inc. or its affiliates and is intended solely for the use of the intended recipient(s). If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies in your control and contact us by e-mailing to security(a)mavenir.com. This message contains the views of its author and may not necessarily reflect the views of Mavenir Systems, Inc. or its affiliates, who employ systems to monitor email messages, but make no representation that such messages are authorized, secure, uncompromised, or free from computer viruses, malware, or other defects. Thank You

4 6

glibc version mismatches in CI
by Jeff Trull 28 Aug '24

28 Aug '24

Hi folks, While reviewing the Modular Boost changes for Wave I noticed that our CI is now failing - and we're not alone in this. It looks like the version of glibc in some of the old Ubuntu containers, which are required to compile against old versions of gcc, is incompatible with the Node executable that runs actions/checkout@v2 (and 3 and 4). You might see errors like this: /__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node) The Github blog discusses the change here <https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-ru…> At least one brave pioneer, Andrey Semashev, has made updates to make CI green again in a handful of libraries, but I haven't seen it discussed on the list. Is there a fix other than "rewrite using manual checkout"? I managed to implement the workaround described in the blog post by adding these lines close to the top of ci.yml: env: ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true Though it seems unwise to rely on in the long run. Best, Jeff

5 5