- Boost - lists.preview.boost.org

CODE_OF_CONDUCT.adoc
by Vinnie Falco 23 Sep '24

23 Sep '24

The subject of a code of conduct has come up a few times, and I think it is worth having a discussion. I hope that everyone will find the following statements uncontroversial: 1. Social spaces have rules, either stated or implied 2. Rules need to state clearly what is allowed and what is disallowed, so that people who may be interested in joining can determine if the culture is the right fit. 3. Rules need to be enforced 4. The Boost mailing lists already have rules 5. The rules for the mailing list are outdated 6. The rules for the mailing list are not particularly visible There is value in refreshing the rules for the Boost mailing list, which are currently described here: https://www.boost.org/community/policy.html I think we should do the following: * Update the rules to be relevant for 2024 * Make the rules visible on the sign-up and administration page for the mailing lists (at https://lists.boost.org) * Consider renaming the rules to something other than "Boost Discussion Policy" * Send a periodic announcement to the mailing lists reminding everyone of the rules. These could be timed to coincide with the releases (three times per year) The community needs to discuss the things above and come to a consensus. And we need to make a final decision on what the changes will look like given the feedback. I don't know that the review process is right for this, because it will likely be an iterative process where we all work on a "shared document" to make edits. The nice thing is that we don't need to wait for the outcome of the Boost Asset Stewardship review to do this, because the content of the website and mailing lists is not controlled by the Boost Foundation, the C++ Alliance, or the proposed Steering Committee. And even before the need to decide which revision of the updated rules will be accepted by the project, discussion can take place with no governing body. There is one hiccup though. Where do we discuss this? The mailing list is one possibility. However, anyone who joins the mailing list late, or is not a member of the mailing list, has the problem that the visibility of the discussion is not very great. They would have to use the archives, and the archives are not very pleasant. One cannot see the entire discussion as a single page. And if someone changes the subject, then new related threads of conversation become more difficult to find. And at the end of the day, our workflow requires GitHub issues to triage and assign work items to staff. Therefore, here is a GitHub issue for this. Everyone can feel free to participate in a discussion there. Alternatively, if you feel that the mailing list is a better place, then reply to this post and have a discussion here. There might be two discussions. Or one. Or none (hopefully not). And when we are done we can compare the pros and cons of GItHub issues versus the mailing list. There could be value here. This is the issue: https://github.com/boostorg/website-v2/issues/1269 What do you think? Thanks

3 4

Asset Stewardship Review
by Adam C Getchell 23 Sep '24

23 Sep '24

I support the C++ Alliance proposal to transfer assets and form a new Steering Committee. I’ve been a downstream user of Boost for more than a decade for my research project, and joined the mailing list to get help on using the project effectively. My initial interactions were to sort out build errors, which were mostly resolved with the adoption of vcpkg (after trying biicode and then Conan) and the work on making Boost compatible with CMake. I have appreciated the C++ Alliance’s sponsorship of tools such as the Slack workspace and CI, and I believe this is necessary to ensure progress. I also learned a lot reading the documentation and code of Louis Dionne’s Boost.Hana and Vinnie Falco’s Boost.Beast. As a side note, my research involves writing low-level simulations of the universe, and unfortunately the various memory errors and other bugs have convinced me to go reluctantly down the path of using Rust to write low-level memory-safe abstractions that I can count on to run for months at a time without segfaults or other issues that compromise the validity of the data. Thus, Circle and the recent Safe C++ proposal are very interesting to me, and if they are ever adopted I might back port them to my current codebase. However, this probably won’t be effective until the libraries I depend on make similar efforts. By then, I will probably have everything I need written in Rust. -- Adam Getchell https://adamgetchell.org <https://adamgetchell.org/>

1 0

Boost.LEAF in Embedded Systems (CppCon)
by Vinnie Falco 23 Sep '24

23 Sep '24

At CppCon 2024 the C++ Alliance sponsored a program to interview conference goers about Boost-related topics. This is the first video in the series: Boost.LEAF in Embedded Systems: Insights from Ex-Google Engineer Khalil Estelle at CppCon https://www.youtube.com/shorts/BksBxnTLltY Enjoy! Thanks

1 0

Boost Asset Stewardship Review begins today (3rd Sept)
by Glen Fernandes 22 Sep '24

22 Sep '24

Dear Boost community, The Boost Asset Stewardship Review begins today, 3rd September and ends on 22nd September. For reference, the review schedule is: https://www.boost.org/community/review_schedule.html The submission which initiated the review is the following proposal from the C++ Alliance: https://cppalliance.org/pdf/Fiscal-Sponsorship-Proposal.pdf It proposes a Fiscal Sponsorship which: 1) is a legal agreement where the C++ Alliance holds assets on behalf of the Boost project. It proposes a newly formed (steering) committee that would be composed of Boost developer community members that would determine how the assets are used. 2) donates the assets that it funds to the Boost project (domains, hosting, etc.) The "Boost developer community" here refers to: - Boost library authors - Boost library contributors - Boost release managers For a high level overview of these terms (which I needed) see the following email with definitions: https://lists.boost.org/Archives/boost/2024/09/257579.php The Boost Foundation asks the Boost developer community to consider the following alternative: https://docs.google.com/document/d/1XFt7Bh71e4_uE0iK4jifhR__P0iG5_c1cDfBsMj… The Boost Foundation proposal presents a path forward where it continues to be the steward the assets in question, but offers a change in how these are managed. The assets here refer to the following: - The boost.org domain - Website hosting - Mailing lists - Downloads storage and CDN - Drone CI Currently, the Boost Foundation owns and pays for the following: - Website hosting - Mailing lists The C++ Alliance pays and manages for the following: - The Drone CI - The CDN for the downloads - The download archive - Technical assistance and support for the Boost release process - Backup domain names (in case boost.org expires) - Hosting and downloads for the new website prototype (boost.io) The boost.org domain is absent from both lists above: The Boost Foundation technically does not own it yet. The domain was owned by Beman and he had the credentials. The Boost Foundation is working with Beman's widow and the Dawes Estate to transfer ownership to it. For reference, see Kristen's email: https://lists.boost.org/Archives/boost/2024/08/257563.php Note that the content of the current boost.org site and the new boost.io website is still the province of the Boost developer community. 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. Please send all reviews to the Boost developer mailing list. If you do not want to create an account, you can email me at glenfe -at- boost.org with your review and I will post it to the list for you. Include "Asset Stewardship Review" or "Asset Stewardship" in your email subject. In your review do disclose any affiliation to either the C++ Alliance or Boost Foundation groups. Please state any connection you have to Boost (developer, user, package manager etc.) Thank you, Glen

15 26

Boost Asset Stewardship Review concludes 09/22
by Glen Fernandes 21 Sep '24

21 Sep '24

Everyone, Tomorrow (September 22) is the last day to submit a review. To date there have been no requests for an extension. I have received suggestions for potential reviewers I should reach out to, and I believe only one review is forthcoming. Thank you to everyone who has submitted a review, or has otherwise contributed to the discussion. Glen (I was reminded that there are still answers pending from certain members of the Boost Foundation. I understand that CppCon is ongoing and they might not be able to reply yet).

1 0

Re: [boost] Boost Digest, Vol 7346, Issue 1
by Alfredo Correa 20 Sep '24

20 Sep '24

Hi Seth, On Fri, Sep 20, 2024 at 5:00 AM <boost-request(a)lists.boost.org> wrote: > > Date: Thu, 19 Sep 2024 16:28:28 +0200 > From: Seth <bugs(a)sehe.nl> > > On Thu, Sep 19, 2024, at 1:13 PM, Artyom Beilis via Boost wrote: > > 1. You haven't mentioned even once OpenCV > > [...] > > 4. If you do implement many high performance algorithms this library by > any > > means shouldn't be header only. > > > > What is not clear to me is why should I use one over some existing > solution > > like OpenCV? > > All of the points raised are actually a single one, and seem to > misunderstand the scope of the library? I suppose it should be seen as a > successor to Boost MultiArray, leveraging modern language features and > side-stepping some of the pitfalls. > yes, exactly. You seem to understand exactly what I am talking about. (Also a big fan of your Stackoverflow answers). I just gave a long answer to Artyom's message in the list. > That's not at all useless, and interop examples would be very valuable. > However, not all code needs vectorization (beyond what the compiler will > automatically do). I'm more interested in the relation to > https://en.cppreference.com/w/cpp/container/mdspan - which seems to fill > the same space: building block for flexibly indexed contiguous storage. > >From this section: https://gitlab.com/correaa/boost-multi#substitutability-with-standard-vecto… "Multi-dimensinal arrays can interoperate with C++23's non-owning mdspan. Preliminarily, Multi's subarrays (arrays) can be converted (viewed as) mdspan." https://godbolt.org/z/aWW3vzfPj Also see https://gitlab.com/correaa/boost-multi#appendix-comparison-to-other-array-l… Thank you, Alfredo

1 0

Video on Boost.Cobalt available
by Richard 20 Sep '24

20 Sep '24

Utah C++ Programmers has released a video on the Boost.Cobalt coroutines library: Using Coroutines with Boost.Cobalt <https://www.youtube.com/watch?v=yElSdUqEvME> -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

2 1

Asset Stewardship Review
by Phil Endecott 19 Sep '24

19 Sep '24

I've been a Boost user and subscriber to this mailing list for most of this century, but I'm not a library author. It's tempting to write a long navel-gazing essay about the history of Boost and what it needs to do to remain vital, and then to pretend to forensically study the competing proposals to determine which will give the best result in the longer term. But in this post I'll try to be more honest: isn't this review more like a referendum on whose side we favour in the Vinnie Falco vs. David Sankel clash of personalities? Somehow we've reached a point where "this town ain't big enough for the two of them" and we're being asked to choose who to exile. What do I think about the Boost Foundation? I have always been mystified by why the Foundation, and the Steering Committee before them, have interacted so little with the list. The most extraordinary example of this was that the very establishment of the Foundation was not announced to the developers! Periodic, brief updates on Foundation activities to the mailing list would not have taken much effort could even have resulted in more offers of help. The foundation's present proposal starts by talking about "Transparency"; perhaps they would be more transparent in the future, but that would be a departure from how they have worked in the past. Regarding Vinnie and his C++ Alliance, I've not had a very positive view of them since he posted this back in 2023: "Something which should not surprise anyone is that I despise paying taxes." This statement is repeated in his current proposal. Personally, I'm proud of the tax that my business and I pay as it funds education, health, pensions and other public services that make my community a better place in which to live. In the world I inhabit, this is a mainstream view. It's one thing to despise paying taxes, but I think it's quite another to tell everyone that and assume that they share the same view. When I read that the boost.io domain for the "temporary" website had cost $135,000, my reaction was that you could feed a lot of hungry children with that sort of money. My conclusion is, "a plague on both your houses". I fear that Boost is doomed. This review will result in Vinnie's hostile takeover succeeding, but eventually he'll lose interest - maybe when the "young developers" that he hopes to attract don't materialise, or maybe after another falling-out with someone else. Then the project will sink. I think this is the right time for me to unsubscribe from this list; being here doesn't help me, and my contributions don't seem to help anyone else. I extend my best wishes and thanks to all those whose libraries I have used over the years. Regards, Phil.

6 5

Re: [boost] proposal Multi multidimensional array library
by Artyom Beilis 19 Sep '24

19 Sep '24

Hi, Only now have I noticed this proposal, and here are some of my thoughts. It can be excellent to have something like standard MD arrays like numpy is today for python, but... 1. You haven't mentioned even once OpenCV which today is the de-facto standard for numerical computing in today's C++ world. While it isn't perfect - it actually has similar features in terms of array layout - and what is more important it has a library of high performance algorithms to process the data. You must talk at least about interoperability between cv::Mat and this library 2. While actual ndarry handling is nice, it is basically a tip of an iceberg. You need a decent set of high performance algo combined with it. Looks like there is a basic BLAS but the typical library has way-way more to make it useful. I looked over the code and didn't find include to cblas... Did I miss something? Also I see request to link cblas/openblas or so. I did breef look into implementation and it seems to be lacking of vectorization (use of intrinsics/vector operators) or have I missed? 3. Finally I do want to see comparison with stuff like OpenCV, Eigen and even uBlas (I know it isn't good) 4. If you do implement many high performance algorithms this library by any means shouldn't be header only. What is not clear to me is why should I use one over some existing solution like OpenCV? Artyom On Thu, Apr 27, 2023 at 12:30 AM Alfredo Correa via Boost < boost(a)lists.boost.org> wrote: > Hi all, > > My name is Alfredo. > I would like to propose this library called Multi for inclusion in Boost. > Multi is a container and views library for (dynamic) multidimensional > arrays. > > The library is available here, > https://gitlab.com/correaa/boost-multi. > >

2 1

Boost Asset Stewardship Review begins 09/03 (Updated)
by Glen Fernandes 18 Sep '24

18 Sep '24

Update: The Boost Foundation proposal mentioned in the original announcement has been published. The Boost Foundation proposal is attached to this email: BoostFoundationStewardshipProposal.pdf A link to the above will also be available in the review commencement email that will be posted on 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 The original announcement email included an attachment of the above: https://lists.boost.org/Archives/boost/2024/08/257569.php - Glen

19 47

Boost Asset Stewardship Review from René
by René Ferdinand Rivera Morell 18 Sep '24

18 Sep '24

== Distractions: Before I get to the meat of the review I need to point out that I will not talk about: if Boost needs a new website, whether Boost needs to be revitalized, if policing communications in Boost is a good idea or not, if Boost is relevant any longer, what build system Boost should use, what documentation system Boost should use, if Boost is attractive, if some other project is the new-old Boost, if Discord is better than email. All of those, and more, are distractions to the key questions that we are deciding on: * Who should manage the assets that sustain the development of Boost Libraries? * Who should decide how those assets are managed? == Disclosure, Present Seeing as the C++ Alliance proposal lists me as one of the initial members of a new Committee I thought I'd include additional biographical background for those that may not be aware of what I've done, and do, both in the foreground and background of programming. In case some are not aware I wear many hats in my life. And some of them intersect with the Boost community. Because of the kind of work that I've traditionally done, and still do, in game development and contracting in that domain I have learned to compartmentalize facets of my life. And how to reorient my thinking to each facet as needed. Below is a very brief exposition of current and past involvement arenas. *Chicago Developer Development NFP* I currently serve as a member of the board of the Chicago Developer Development NFP. This is a non-profit that manages the finances of the Chicago C/C++ User Group. Although the non-profit is very new, the user group has been around for almost as long as Boost. And I've helped manage it for just about as long. *Disbelief LLC* My day job for Disbelief is now at about 9.5 years doing AAA game development consulting. Mainly doing Unreal Engine systems and graphics programming. The one intersection with Boost here is that we happen to use Boost in an internal project. And Boost is used in the internals of Unreal Engine (at one point it had at least 4 different copies of Boost in it at once). *C++ Alliance* I currently serve as a member of the board of the C++ Alliance and hold the position of Secretary. As mentioned in the C++ Alliance proposal my duties include advising on the non-profit operation and alignment of initiatives with the goal of advancing the C++ ecosystem. My experience in Boost and running various nonprofits and for-profit corporations is particularly useful. The C++ Alliance also makes it possible for me to participate in WG21 where much of my time has been spent in C++ tooling and the standardization of tool interop. *Boost C++ Libraries* I currently maintain Predef and B2. I am currently working to make the B2 build support in Boost allow for modular usage. With the hope of making it easier to support package managers and the desire from some users to depend on just the Boost libraries they need. In the past I created the current Boost website, which is the second iteration. I provide advice on the development of the new website. I provide advice on the packaging of Boost for Conan. I maintain the B2 Conan package which is separate from the Boost Conan package. In the past I've also served as Boost Documentation Manager during which I helped maintain Quickbook. I also served as Boost Release Manager during which I automated much of the labor using cloud CI. I also served as Boost Testing Manager during which I tried, but failed, to improve the global test matrix but at least kept it running. And long ago I minimally helped to start BoostCon. *Bincrafters* Bincrafters is a group that got started at the early stages of the Conan package manager. We created many packages for libraries of all sorts. I joined at its foundation to do one main task, to create the first modular set of Boost packages. Although that modular Boost packaged release is no longer available it taught me many lessons that I applied to the current modular B2 building. That effort also provided the conceptual model for the current modular vcpkg Boost packages. Currently the group does minimal support of some existing packages. But otherwise we've ported most of the packages we created to the public Conan Index. Of particular relevance is that we organized using the Open Source Collective as a Fiscal Sponsor (https://opencollective.com/bincrafters) == Disclosure, Past As the past is an indicator of the future I thought it important to also include some of the related organizations I've been part of before now. *Redshift Software* I was President of a software development S-Corp that did all kinds of contracting projects during the 16.5 years it operated. We did everything from tools, games, and web sites. It was during the early days here that our need for a build system for the version control system we developed came from and how I came to find Boost. We went on to use Boost heavily during that time. Which necessitated myself fixing bugs across many of the Boost libraries. This is also where I taught myself how to run a corporation, by reading Illinois corporate law books and IRS rules. *Couchworld Games* I was also President of this game development C-corp (minor note, I was "volunteered" for the position in this one and in Redshift). Even though this corp got created to develop some AAA games, we ended up creating some iPhone puzzle games in C++. Which was a rather hard endeavor given the iPhone ecosystem in the early days. And, yes, we used Boost and B2 in the engines we developed for those games. *BoostPro Computing* BoostPro was a consulting company started by Dave Abrahams to support Boost developers by having clients pay for the technical support of their use of Boost and general development for the clients. Some of that work ended up as new Boost libraries. I worked, as a subcontractor, for 3 years alongside Dave, Eric Neibler, and Joel de Guzman. In summary, I've been involved in most aspects of Boost for more than 22 years. == Executive Committee: When I say "Executive Committee" I'm referring to a group that performs actions on behalf of a group. In this case I'm avoiding the "Steering Committee" term as it appears to have additional connotations because of the past use in Boost. I think it's important that I explain what I think how a group (like an Executive Committee but applies to any group claiming an equivalent role) representing Boost developers should operate. For an Executive Committee it is paramount to gain and maintain the trust of the developers. To achieve that, decisions need to have the support of the developers. Actions by an Executive Committee should not come as a surprise to developers. >From the beginning of my interactions in Boost I learned one key fact.. Progress got made by those that acted and obtained buy-in from the Boost developer community. Of the various achievements Boost created early on, the one that made it possible to get such buy-in, has been the community review process. It is a bottom up process that is designed to remove doubt from the ethos of Boost. It is the community review process that we are using now to clarify how Boost moves forward, and hopefully upward. It should be the process that we follow for Boost developers to make decisions about the assets that sustain Boost development. And it should be the results of such a process that the group representing Boost developers accept as binding to make further decisions. I am hopeful that the machinations we are currently following will become the norm. Some have mentioned concerns about conflicts of interest in our governance moving forward. Irrespective of my current inclusion in the proposed composition of the Committee by the Alliance, it is my hope that any future Committee will adopt policies that uses the Boost Community Review process to drive decisions. Any actions the Committee makes, including, but not limited to, its future composition, should have community consensus by the time the Committee votes. It is the only fair, open, and clear way to make decisions. == Inclusivity: As this topic has been mentioned a couple of times I feel like I need to explain my philosophy on this and some related context. I believe that a varied set of ideas and understanding is essential to any life endeavor. As such I believe that keeping doors open to conversation is key in understanding and inclusion. Even though I think that words are important, I place actions above rhetoric. In other words, I think being a decent person is more important than telling others how they should be decent. My philosophy likely stems from learning to live with conflicts in my life. I became an immigrant to the US when I was a teenager. I'm also not an immigrant because I was born in Puerto Rico with US citizenship. English is not my native language. But I am also more fluent in English than my native Spanish. I am a straight man in a field (game development programming) dominated by straight men. I am also Hispanic in a field where they are an underpaid minority. Part of my ancestry is European and originates in Mallorca, Spain and further back in Catalonia. Another part of my ancestry is Native American of the Caribbean Taino Civilization. Even though I came to Boost searching for a build system, that is not what kept me in Boost. And it was not racial, language, biological (I say that one from the perspective of having a name that is often confused as female in the US), theological, or cultural inclusivity that kept me in Boost. It was intellectual inclusivity that has kept me here for more than 2 decades. It was, and in my opinion still is, a community where I can expect an honest consideration and assessment of technical ideas. == Are you knowledgeable about the problem domain? Yes. I have managed for-profit companies. I have helped, and currently help, to manage non-profit companies. I am versed in managing organization assets of those companies. == Proposals: Given all that preamble, below is my review of each proposal. Foundation:: I found this proposal spent most of its wording explaining the ethos it aims to operate within. It is helpful to get that detailed exposition as it has been something that has been missing from the Foundation (and the SC before it) for a long time. What I see in that exposition though is in dissonance with my experience. The mentioned transparency is limited in time, the past two years publishing minutes, and scope, process on how decisions like board membership are made have been lacking. Consensus building is mentioned as a core aspect. But it is unclear how the consensus process is achieved for Foundation decisions that impact Boost. The items mentioned as the actionable parts of this proposal are "Community building", "Improve relevance", and "Adopt governance best practices". Of those, the one that enumerates some steps that apply to the stewardship of Boost assets is the last one. The first three items, as far as I understand, apply to how Boost developers operate and make decisions as envisioned by the Foundation. The fourth and last items pertain to how the Foundation intends to improve its composition with, I can only assume, the intent to increase participation from Boost developers. The fifth item is the only one that directly addresses the aspect of managing Boost assets. Outlining how the Foundation would take control, and possibly ownership, of assets. But it doesn't mention which assets. Is the library source an asset in this model? Who decides which assets? What this proposal lacks throughout is consideration for accountability to Boost developers wishes. While placing all control in the Foundation. This is an arrangement that would require the utmost trust in the Foundation by Boost developers. And given past history I don't see evidence of such a level of trust being merited. Alliance:: The background of the proposal is thoroughly researched and explained in detail. Although there is a fair amount of background information in the proposal I think it can be summarized as "it gives Boost developers control over Boost assets through a Steering Committee". And although this specific proposal is for the Alliance to be the Fiscal Sponsor that is, as we like saying, "an implementation detail". As the control of what happens with the assets goes to the Committee who represents the Boost developers. The proposed Transition Plan recognizes the roles of the various parties and does a good job of remunerating the parties for the work in the transition. The operation of such a Committee and the Agreement match what I know of the requirements for managing non-profit assets. == Conclusion: I support the C++ Alliance proposal to transfer assets to it and to form a new Steering Committee. There are various details to be worked out if the proposal is accepted by the Boost community. For example, the name of the Committee, its final composition, a final contract, and so on. But that's expected, and natural to achieve a structure that the Boost community can grow with. Thank you for reading this far, René

2 1

[cmake] Define CMAKE_PROJECT_VERSION for standalone subprojects
by Lucas Colley 18 Sep '24

18 Sep '24

Dear boost developers, Subprojects like `math` define CMAKE_PROJECT_VERSION in terms of BOOST_SUPERPROJECT_VERSION via: ``` project(boost_math VERSION "${BOOST_SUPERPROJECT_VERSION}" LANGUAGES CXX) ``` This is clearly handy to save a few seconds in the release process, but it means that if one wants to use the subproject standalone (where BOOST_SUPERPROJECT_VERSION is undefined), CMAKE_PROJECT_VERSION is also undefined. This is a problem for me as I am trying to make boost_math a Meson-CMake subproject of SciPy. This would enable us to un-vendor boost_math from SciPy, such that a distro can instead use SciPy with boost_math as a system library. We would only fall back to embedding the boost_math source when it is not installed as a system library. When the boost_math source is embedded, CMAKE_PROJECT_VERSION is parsed to check that we have the correct version to work with SciPy, but we get an error that the version is undefined. This could be solved by defining the version directly in the math subproject instead of in terms of BOOST_SUPERPROJECT_VERSION. The alternative solution of embedding the entire boost source is not suitable for us, since all we need is math. Would it be possible to switch to defining CMAKE_PROJECT_VERSION directly in subprojects? Or is there a more compelling reason to define it in terms of BOOST_SUPERPROJECT_VERSION? Cheers, Lucas — For context: https://github.com/mesonbuild/meson/pull/11730#issuecomment-2351619977, https://github.com/scipy/scipy/pull/21270

3 3

Re: [boost] proposal Multi multidimensional array library
by Andrzej Krzemienski 18 Sep '24

18 Sep '24

śr., 26 kwi 2023 o 23:38 Alfredo Correa via Boost <boost(a)lists.boost.org> napisał(a): > Hi all, > > My name is Alfredo. > I would like to propose this library called Multi for inclusion in Boost. > Multi is a container and views library for (dynamic) multidimensional > arrays. > > The library is available here, > https://gitlab.com/correaa/boost-multi. > > The Boost prefix is purely aspirational at this point, of course. > As I understand the process, the important step at this point is to > find someone(s) to endorse the library and later a review manager. > If you want to be an endorser, please let me know. > > If anyone has feedback or tips to prepare it for a review, please let me > know as well. > I will be at the Aspen CPPNOW conference if someone wants to discuss it in > person. > I am in the C++ Slack channel #boost for discussions as well. > > Here is a link to try it quickly online https://godbolt.org/z/KerbxW6WK. > Hi Alfredo, Thank you for sharing your library. This has been more than a year now, and I am sorry for the delayed response. Thank you for reminding us of it in the slack channel. From this, I gather that the game is still afoot. Recently, it was pointed out in this Mailing List, that it is unfair with respect to the authors to give critical feedback without having studied the proposal, yet I am about to do exactly this. I have only read the introductory part of the docs, as well as the "Comparison with other array libraries" appendix, and my feedback is solely based on that. But you can consider me a good representative of a potential user of the library, who is impatient, and can offer only 5-10 minutes to decide if they want to invest more time in studying the library. This is in the spirit of Roert Ramey's advice: https://www.youtube.com/watch?v=ACeNgqBKL7E&ab_channel=CppCon I personally never needed to manipulate big multidimensional arrays, so I cannot immediately appreciate the usefulness of the library. I need a good introductory part. When I read the high-level description, I immediately think, "it is the same as std::mdspan". The docs say that it is different from the std::mdspan, but then I think, "no, it is the same as std::mdspan". >From the comparison table, I gather that Multi offers both the container and the views (sort of references), and that std::mdspan is only a view. Am I right? The docs say that Multi provides value semantics, but I guess it is not a fair statement. I guess (and correct me if I got this wrong) that the container is value-semantic, but the views are not. That is the nature of the views, that you want them *not* to have value semantics. A fair comparison, should compare Multi's views to std::mdspan. Now, the Standard library has also a proposal in flight to add a container for multi-dimensional arrays: std::mdarray: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1684r2.html Could you also include it in your comparison? And I would expect that std::mdspan and std::mdarray are treated as one in this case. I read that Multi's types have an STL-compatible interface (range). But this is far from obvious what it means in the context of multi-dimensional arrays. The range/iterator interface was tailored for one-dimensional data structures. There is no obvious generalization to multiple dimensions. I wouldn't even expect a multi-dimensional array to give me an STL interface (whatever that means). Maybe, you mean that the library offers a view where you can see the entire multidimensional array as a long string of values? This would make sense, but if it is the case, I expect the introduction to say exactly this. In the case of std::mdspan, it has been said that it has been tailored to efficiently represent both huge datasets as well as tiny 4x4 matrices. I am not sure if this is the case, but I request that the docs for Multi say what use case they have been designed and optimized for. Does the library only represent dense matrices, or can it also represent sparse data? The term "stride-based". It is not clear to me what it means. I cannot see from the introduction if this library will throw exceptions. The comparison between Multi and std::mdspan in the row "const-propagation semantics" is unfair. I guess you are comparing Multi's container with a view. A view is not expected to propagate constness. So this is the very initial feedback, I hope it helps. Regards, &rzej;

4 5

[Asset Stewardship] About the Beman Project
by Andrzej Krzemienski 17 Sep '24

17 Sep '24

Hi Everyone, The review hasn't started yet, but I think there is no harm in starting the discussion earlier. The Fiscal Sponsorship Proposal from C++ Alliance has the following statement. At the C++Now conference in 2024, the Foundation launched a competing > library collection called the Beman Project, describing it as “a new > initiative separate from Boost that gets back to its original purpose of > improvements to the standard library.” Could perhaps directors of the Boost Foundation comment on their affiliation with the Beman Project? The reason I ask is that my perception of the Beman project, given the scarce information about it online, and the observation that C++ proposal authors prefer to avoid Boost, is "Boost doesn't work, let's start something new". Regards, &rzej;

24 56

Safe C++ and Boost
by Vinnie Falco 17 Sep '24

17 Sep '24

Hi. I am proud to announce that the C++ Alliance has entered into a partnership with Sean Baxter to develop Safe C++: language extensions to provide memory safety in C++. Some of you might have seen the official announcements on various social media sites, and I’m here to provide some more information on how this initiative affects Boost. First, I want to express my appreciation for Sean’s enormous technical abilities, and for his stamina to invest eight years of research and development into Safe C++. I believe that his efforts reflect good philosophical principles for improving the language with memory safety extensions: 1. Safe C++ must be a superset of C++: all existing code must work. 2. Safe C++ must allow controlled opt-in to memory safety: expecting the world to rewrite everything in a new language is not realistic. 3. Safe C++ must be developed using an implementation-first approach: a working model is preferable to just ideas. The partnership with Alliance has three deliverables: research the remaining design problems, complete the Safe C++ Language Extensions proposal for standardization, and implement the Safe C++ Standard Library. The safe library is a set of additions to the standard library providing essential vocabulary types and algorithms needed by users to achieve memory safety. We don’t know that Safe C++ is the final solution for memory safety in C++. Perhaps the required extensions will be so intrusive as to make it effectively a new language. Maybe the language features which allow for zero-cost abstractions are so powerful that they can’t be preserved in ways that are memory safe. Yet there is value in pioneering this design space that Sean has carved out. It is also possible that Safe C++ becomes the winning memory safety story for C++. We at the Alliance believe it is worth taking the chance to find out. Through the relationship with Alliance, the Boost community has a unique opportunity to participate in helping to explore and solve the remaining difficult design problems, and a front-row seat to the latest draft of the Safe C++ proposal which can be viewed here: https://safecpp.org/draft.html If you would like to discuss Safe C++ in real time with other engineers please join the #safe-cpp channel in the Official C++ Language Slack Workspace by signing up here: https://cppalliance.org/slack What does this mean for Boost? There is a tremendous opportunity here for Boost to innovate ahead of the C++ Standard. I envision the scenario where some volunteers will port selected Boost libraries to Safe C++ as a proof of concept. The porting process will surface areas of the proposal which need work. As memory safety is rapidly becoming the defining feature of modern mission-critical software development, the opportunity for Boost to lead in this area may attract the needed revitalization of the project in the form of new volunteers. Please join us in helping to define this exciting chapter of the C++ language! Thanks

5 8

Boost Asset Stewardship Review
by hans.dembinski＠gmail.com 16 Sep '24

16 Sep '24

I vote to accept the proposal of the Boost Foundation. I am neither affiliated with the C++ Alliance nor with the Boost Foundation. I am the developer of the Histogram library, which sees a lot of use in the scientific community. My personal values are aligned with the Boost Foundation and its supporters. My observation is that the C++ Alliance uses money to gain influence over this community, for example, by paying some community members to work on projects, and through its donations into the infrastructure. I want Boost to be a non-hierarchical community based on volunteer work, inclusivity, transparency, and consensus. The community is developing away from this ideal, as the C++ Alliance has taken an increasingly dominant role. While my decision here may not change that trend, I cannot support a proposal which would further increases their influence. Hans

3 2

On how to write good documentaiton and why
by Andrzej Krzemienski 16 Sep '24

16 Sep '24

Hi Everyone, While reviewing a Boost candidate library, I re-watched Robert Ramey's advice on how to write library documentation, from CppCon: https://www.youtube.com/watch?v=ACeNgqBKL7E&ab_channel=CppCon https://www.youtube.com/watch?v=YxmdCxX9dMk&ab_channel=CppCon These are so great talks, and so much practical, wise and appealing advice. Whenever my colleagues ask me for advice on how to write documentation, I give them these links. I also follow the advice ever since I watched the first video. Robert, thank you for them. I believe that this is a valuable Boost asset, and should be listed along the Boost Software License and the Boost Review Process. I hope that our documentation (old or new) will mention it in a prominent place, much like the docs mention the great article "Exception-Safety in Generic Components" by Dave abrahams. Regards, &rzej;

1 0

Page on the website clarifying Export Status
by Glen Fernandes 15 Sep '24

15 Sep '24

Every now and then (most recently, two days ago), I get a question asking if we have an ECCN in compliance with US export control laws. ECCN is an Export Control Classification Number. (More details at the Bureau of Industry and Security website : http://www.bis.doc.gov/ for anyone interested). We fall under "Not Controlled", so we do not have such a number. (Ion, as a heads up, you will probably start getting these kinds of questions now too). We should probably put this somewhere on our website. FAQ or a page on itself. Any concerns or comments? Glen

1 0

[Asset Stewardship] Andrzej's review
by Andrzej Krzemienski 15 Sep '24

15 Sep '24

Hi Everyone, This is another review in the context of the Boost Asset Stewardship proposal(s). I am not affiliated with either the C++ Alliance or the Boost Foundation, although in the past I talked with the Alliance about the potential compensation for my contributions to Boost, and I represented the Alliance in one WG21 meeting, in Rapperswil. I maintain Boost.Optional library, try to contribute to all Boost reviews, and have managed the review of Boost.SafeNumerics library. I consider myself a Boost Developer. The subject of the review is, which legal organization formally owns the Project's assets, and who actually manages them. But the questions I, as many others, am trying to answer is: * What is going to be the shape and the popularity of Boost libraries? * Where will the funding come from? * What will the Boost community look like? * To what extent will the Boost community be in control of things? The tricky part is that the goal of the Boost Foundation in the past, as well as the future goal of whoever will manage the Boost assets is so that the developers can focus on the development, and need not study the administrative and financial stuff. Yet it is the developers that need to make the decision regarding the administrative and financial stuff now. One thing that I didn't have to pay attention to in the past, and now is becoming clear to me, is that in order to be able to host a host of libraries, test them continuously, improve the infrastructure tools, and build new tools (like the one for documentation), costs huge amounts of money (by my standards). It is my understanding that this cost has been primarily covered by the C++ Alliance. But it is also my understanding that this happened under the Boost Foundation's government, and theoretically the C++ Alliance could continue to make financial and technical contributions under the government of the Boost Foundation. I also hear that this is practically impossible, for reasons that are not all clear to me. I understand that there are fundamental differences in philosophy. The Boost Foundation has the volunteer model, where people devote their private time as their lives permit, and that the C++ Alliance is an organization with huge funds, and the capability to employ people. I also understand that it is a risk for the C++ Alliance to invest huge assets in the Boost project, knowing that ultimately the efforts can be torpedoed by the decisions of the Boost Foundation. I am not saying that this is or has been the case. I am only pointing out the obvious consequences of the mistrust. The Boost Foundation is volunteer-driven. This means that people work on what is deer to their heart, and if something is not deer to anybody's heart, it may not be done, even if important. The volunteers can only put as much effort to their work as their private life permits. This means sometimes they have to give up. The effect might be that a volunteer-based organization may appear unreliable. On the other hand, volunteer work inspires more volunteers. I was surprised to find that the Boost Foundation's, as it is today, primary goal is not to support Boost's interests: it supports many initiatives, Boost being one of them. I was misled by the name. People, including myself, have pointed out that the support for the Beman project is somehow in conflict with supporting Boost. But having thought more about it, I no longer feel this way. I am now inclined to think that the Beman project is the best thing that could happen to minimize the damage caused by the current process of standardizing libraries in WG21. So if there is any glitch in the Boost Foundation, it is the support for some proceedings in WG21. This is because WG21 innovates and experiments, instead of standardising the things that work. I think the Boost Foundation has been doing a good job at steering Boost. If people feel that "they are doing nothing", this might be the indication of the job done right: Boost is rolling, the lights are on, the Foundation is not getting in the way of the developers. Most of the job done is invisible. The question is, can we still improve if we adopt the Fiscal Sponsorship Agreement from the Alliance. I understand that the Agreement gives the Alliance the sense of stability: that the efforts that cost years and millions will be integrated. This would help secure the development of essential components that we need: * the modularization * the platform for communication that is open for the young, while not discriminating the old (like myself) * a tool that helps produce documentation. Except for the first, I do not think they can be achieved without a substantial financial effort. Risks: * With this huge and single source of income, we will be looking more like a company than a volunteer organization. * It is likely that because of this Boost will not attract new volunteers * It is likely that no-one else will feel the need to sponsor Boost. But even if some of these risks were to materialize, the value of having a tool for writing documentation for C++ libraries is so huge: it goes beyond Boost. My concern from a different level is that after all the chaotic and unpleasant (mis)communication in the Mailing List, I am left with the impression that the C++ Alliance is ready to break the established rules in order to achieve the goals. This may be a deeply unfair statement, but I can't help it: this is what the shreds of information that I receive suggest. The proposed Agreement attempts to secure the Boost project against the situation of an irresolvable conflict, but no agreement can secure your interests when the agreements are not respected. During this review period I have heard late but honest explanations from the Boost Foundation members that explain their actions and show their motivation, and I find them credible. I do not believe I have heard the account from the C++ Alliance that would help understand what motivated the organization to act the way they did. One last concern is that I am not comfortable with the fact that the proposed Fiscal Sponsorship Agreement re-uses the term "Steering Committee". As indicated in other messages, the Boost Foundation *is* the Steering Committee, or rather continues the tradition of the Steering Committee with the same people onboard (not all, obviously), and with the same ideals. In order to honour them and in appreciation of their work, I think the new setup should not intercept this name. Regarding the question of attracting or repelling new contributors, I find it hard to believe that the enforced Code of Conduct could have a significant impact on the results. In my opinion, what could have a bigger impact is when Boost becomes modular, people can afford to use it more in more contexts, appreciate it more, and some of them decide to contribute. Regarding the Foundation's counter-proposal. I do not find anything material in it. I read it as "let's leave the things as they are, but let's enforce the CoC and increase transparency and efficiency". As I said, I cannot see how the enforced CoC could make a substantial difference. Regarding the efficiency and transparency, I do not find anything substantially wrong with them today: they are good enough. Today we are facing a crisis, but other than that I think the Boost Foundation is doing a good job. The Boost Foundation also mentions the modularization and the new communication platform, but even the Foundation members admit they do not believe that making such big projects would work with the Boost's consensus-based philosophy. In closing, I would like to say that I am grateful to the members of both the C++ Alliance and the Boost Foundation for your contributions to the Boost project and community. I have certainly benefited from your work, in many ways. I recommend accepting the Fiscal Sponsorship Agreement from the C++ Alliance, as I see the potential in it to significantly improve the situation of Boost, and other good libraries out there (I mean the new documentation tool), while recognizing that this is a risky decision. Regards, &rzej;

2 1

Boost Asset Stewardship Review from Ruben
by Ruben Perez 13 Sep '24

13 Sep '24

DISCLAIMER: I'm a C++ Alliance employee Hi all, I'm the author and current maintainer of Boost.MySQL. I'd first like to thank both the Boost Foundation and the C++ Alliance for their contributions and efforts, especially when done in their free time. On the technical side, I particularly appreciate the infrastructure contributions the C++ Alliance has made. The Drone CI has been really important for me even when I was a volunteer, as it's fast and supports Windows Docker images. I also appreciate their efforts regarding documentation, as I share the need to update Boost in this aspect. Of course, their recent sponsorship regarding Boost.MySQL has allowed me to develop the library much further than my otherwise scarce free time would have allowed me. I think the C++Al proposal is good, as it will allow other authors like me to also benefit from infrastructure improvements like the ones I mentioned. C++Al people are pretty technically enthusiastic, which I also like. The concern of letting too much of Boost's decision power in a single organization's hands seems legit. However, the proposal seems to take this into account, proposing several measures to mitigate the risk, with a Steering Committee composed of respected Boost developers. I also support adding Peter and Glen to the committee. I also appreciate the contributions that the Boost Foundation members have made to Boost, and would like to thank them for that. I'd like to echo a point made by others in the mailing list throughout this discussion and also somewhat reflected in The Boost Foundation's proposal, about mailing list friendliness to newcomers. When I first reached out to evaluate the potential usefulness of what would become Boost.MySQL (https://lists.boost.org/Archives/boost//2020/03/248301.php) I received a couple of really discouraging comments, which almost made me abandon the idea. These comments were based on the (somehow understandable) misconception that my library was a wrapper around the official C API. Thanks to other people's support (Richard, Chris, Vinnie and some others, IIRC) I managed to move forward. But it could have not been the case. As a community, we could try to improve instances of this to make things better for newcomers. That said, I think the C++ Alliance proposal moves in the right direction, so I vote to ACCEPT it. Thanks, Ruben.

8 11

The Future of Boost Governance
by Dave Abrahams 13 Sep '24

13 Sep '24

I'm writing to represent the spirit in which Boost was founded and in which we ran it, as a community, up until 2013. I realize the review is nominally about asset stewardship, but IIUC the more fundamental change being discussed is about governance, not who holds Boost's property. Before I moved on to other things, I participated in setting up a steering committee that was supposed to step in and make important decisions when Boost's default "community-based leadership and decision making" process got stuck or was otherwise inadequate. That body, I gather, evolved into the Foundation board. For some purposes, that governance structure has worked, but when it comes to managing Boost's assets, it seems the ball was dropped, and the Foundation did not self-correct. Therefore, I very much understand why one might want to transfer Boost governance to an organization with more apparent energy. All that said I am deeply concerned about recent actions by the C++ Alliance. Please correct me if I'm misinformed about any of this, because as I've said I've been out of the loop. It is my understanding that the Alliance did not communicate to the Foundation or publicize its efforts to gain control of the boost.org <http://boost.org/> domain name. Effective or not, the Foundation is the nominal governing body for Boost, and coordination with the Foundation would have been the appropriate, aboveboard course to take. It is my understanding that despite an agreement to coordinate the launch of a new Boost website with the Foundation board, the Alliance decided to launch boost.io <http://boost.io/> in parallel with boost.org <http://boost.org/>. That move is problematic for all the same reasons. It also creates confusion for the user community about where the real Boost is. These aggressive and unilateral actions seem to be at odds with the spirit of Boost and to be harmful to the coherence of its community. IMO it's very much to the Foundation's credit that they did not respond in kind, but instead opened a discussion about Boost's future governance and offered to abide by the community's decision. That is what I'd expect from a group that truly had Boost's interests at heart. All that is great but it does seem very wrong that the conversation should be prompted by actions like the above, and for me, any outcome that transfers Boost governance to the instigators of those actions compounds the problem. It saddens me greatly that a rift exists between the Alliance and the Foundation, because the energy and commitment of the Alliance members is admirable, and communication here on the mailing list looks like it has been productive. My ideal outcome would be to repair whatever is needed to make the Foundation work as a governing body, and to repair the relationships so that Alliance members can continue to make great technical contributions without feeling like the Foundation is holding up their progress. I'm sure that would be asking a great deal of the participants on both sides, but that's what I'd like. It seems to me any correctives that would result from a governance transition could equally well be applied to the Foundation itself. - Dave

6 6

Domain Transfer Update
by Kristen Shaker 13 Sep '24

13 Sep '24

Hello, I wanted to give everyone an update regarding what is happening with the boost.org domain. We are working with the lawyer representing the Dawes estate to transfer control. However, Beman Dawes was the only one with the credentials, and the transfer process without them is onerous. It may take many months. We intend to continue to provide updates. Warm Regards, Kristen

10 11

Asset Stewardship Review - Halfway mark
by Glen Fernandes 12 Sep '24

12 Sep '24

Everyone, We are halfway through the review period. Thank you to everyone that has participated so far, even if you haven't contributed a review yet. If anyone has yet to submit a review because they are unsure of how to format it, or what you can contribute, hopefully the responses thus far have helped inform that. If not, then I would suggest starting with a vote and your reason, and we can elicit additional information with follow up questions. So far, nobody that has sent me any questions or feedback privately, has expressed that they would like to post a review but don't know how. I have yet to compose (or source) answers to the last set of questions I received, but I will do that this Saturday. Glen

1 0

Asset Stewardship Review
by Vladimir Prus 12 Sep '24

12 Sep '24

Hi, I vote for the C++ Alliance proposal. Right now, my contribution to Boost is limited to accepting small PRs for the program_options library, I don't expect to be very active in the future, so my vote should be suitably discounted. On the other hand, I wrote one library, contributed changes for some others, and worked on building/testing infrastructure, so probably know something. I have no affiliation with either party, though I criticized Boost Foundation before. Many open-source projects have solved the matter of asset management and financial support without much drama. For example, there is the LLVM foundation ( (https://foundation.llvm.org/) which pays for infra, and sponsors developer meetings. There are 9 people on the board, and their bios all mention LLVM contributions. There is a public process to nominate new board members candidates (the current board votes on them, though). The activity of the foundation is fairly visible. There's also the Apache Foundation (https://www.apache.org/) It hosts a lot of projects, and committers run each one. Matters are resolved by committer vote, new committers are added by vote, and inactive members lose their commit/vote privileges. The foundation itself provides resources, like magic garden gnomes. Probably, with a bit more goodwill and introspection, we could have worked out the details and reached the level of those examples. But, we saw divorce paperwork sent in public, and both parties have a long list of grievances, so here we are, deciding who gets the custody. Boost Foundation, in my opinion, has a real identity and credibility crisis. Originally, in the steering committee times, it consisted of project founders, who were active in the project, and contributed lots of hours and probably personal money, while preferring consensus for all decisions. It gradually changed, and these days, Boost Foundation has largely checked out and consists mostly of people privileged enough to travel to Aspen and other conferences. Still, it occasionally issues decrees for the project to follow. Consider the recent events. There was a decree to stop working with a large sponsor. Per meeting notes, 7 people met to make the decision. I see only 2 with obvious connections to the project. Kristen's post with the announcement was her first-ever post to the list. The board members were not nominated, voted, or announced on the list. Despite many raised questions, foundation members had no timely answers. Even during this crisis, most members did not say anything. And then, just today, one member has it was not a degree, but a recommendation and the alliance can still sponsor everything. That's a clear failure. Maybe it would be OK if the foundation provided vast resources, and let developers decide, Apache-style. But right now it's only paying for the webserver. (I am unsure whether that's the foundation, as opposed to a generous foundation member using personal funds). There are no IT resources to keep the server up-to-date, no money to pay for CI/CD and downloads, and official filings merely say "less than $50K of income per year"). Finally, the fact that boost.org domain ownership remains unresolved even after it already expired couple years ago illustrates the lack of time/interest. The foundation's proposal is weak, brief, and seems hastily written. It does not acknowledge or address the issues above. There's no significant revamp of the board, there's no plan to to procure funding, and there's no plan to obtain IT resources. Instead, it proposes a few other things that might be good. However, those things can be decided on the list. It does not require that the foundation holds the assets. Finally, the proposal does not mention the "Beman Project" at all. It's not clear how the foundation plans to support the Boost project, while simultaneously working on an almost identical one. (I wonder if this proposal was intentionally written to lose, and move on) The C++ Alliance, organizationally, is not much better. Its board is Vinnie and his friends. As an extra plot twist, one member of the alliance board was previously on the foundation's board, and at least partially responsible for the current situation. But, things take a dramatic turn after that. The alliance is way more active in the project. Two board members are active contributors. It employs other contributors. There are quarterly blog posts from employers explaining what they have done. There are "transparency reports" about overall activity. That's easily 10x more transparency. They also have considerable financial resources. The last IRS filing claims over $2M per year. There are full-time employees and there is no doubt that they can handle Boost's relatively simple infrastructure. The alliance proposal is fairly smart. It proposed essentially the Apache model. In turn, that means we no longer have to be concerned about the alliance's board - the arrangement lets committers decide everything, while infrastructure just magically works. I do, of course, have some concerns about the alliance. It is sponsored by Vinnie himself, while the foundations I mentioned above have more diverse income sources. Also, some people might consider voting for the alliance as supporting Vinnie personally, or even taking his side in some outside-of-Boost conflicts. (Obviously, it's not). Alliance, at times, has too much money. I doubt that a "modern logo" is at all necessary, seems like a distraction. The estimated costs for the new, still essentially static, website would seem sufficient to run a few AI startups. I am worried that any change in the financial situation will leave us with way too expensive infrastructure. Like, the current server can be sponsored by literally a single developer. The "new website", at $10K per year, is not so much. At the end of the day, I don't see any choice. The Boost Foundation, as an organization, and as individual board members, made a lot of contributions, but as of 2024, there appears to be little financial and human resources, and no willingness to work with the developers. The C++ Alliance, on the other hand, already pays most of the bills and has proposed a schema that will empower the developers. I think others already commented on the details of the agreement. My only proposal/condition is that the members of the new Boost Steering Committee be provided with access to all relevant IT resources (DNS registrar, DNS hosting, any cloud providers) and that they meet with the alliance periodically, like twice per year, and verify that all the access still works. We want to make sure that in the case of any emergency, we're prepared. Thanks, -- Vladimir Prus http://vladimirprus.com

3 2

Boost Asset Stewardship Review from Andrey
by Andrey Semashev 12 Sep '24

12 Sep '24

[Warning! Long post ahead!] Hi, This is my review of Boost asset stewardship proposals from The Boost Foundation (the current governing organization) and The C++ Alliance. I. Are you knowledgeable about the problem domain? ================================================== Not particularly. Although I can probably consider myself an old-timer (I think, I joined the mailing list back in 2007; at least my archive dates back that far), I have never been privy to Boost infrastructure and management details. The only information I know is what was published on the mailing list (ML). I have also never managed a company or organization outside Boost. I am neither a lawyer nor financist, and English is not my native language, so I may misunderstand some of the information given in the proposals. Sorry if that's the case. However, as a Boost library maintainer and user, I am interested in the Boost project's bright future. Specifically, the future where I'd be willing to continue using and contributing to Boost. While this may sound selfish, my hope is that my contributions will also make Boost more useful to others. So, my review will be written mostly from a maintainer's and user's perspective rather than someone knowledgeable in the problem domain, which is primarily asset management and legal relations between organizations. I am not affiliated with The C++ Alliance or The Boost Foundation. II. The problem statement ========================= In order to evaluate the proposals, I will first state the problem, as I understand it. Then, I will see how each of the proposals addresses it. I will separate the problem description into three aspects: 1. Boost popularity decline. As stated in both proposal documents, Boost popularity has declined in recent years, based on metrics such as the number of posts in the ML, the number of submitted libraries or the number of git commits per year. The C++ Alliance proposal provides the relevant data in Appendix 2. My personal perspective is that *volunteer participation* in Boost is indeed reducing. Here, by volunteers I mean contributors that are not staffed by The C++ Alliance and contribute their work independently. It appears like Boost "went out of fashion" and going though a Boost review is too difficult and time consuming for newcomers, and so they are picking easier alternatives to publish their code and ideas and gain recognition. In doing so, new developers seem to be willing to trade the quality of their solutions for popularity and quick gains. I'm not entirely convinced that this lack of participation is caused by how modern our website looks or how often we post news items on social media. While these things do matter, I suspect the fundamental issue is that newer developers simply don't want to bother with the review process and responsibly maintaining code afterwards for various reasons. I find this tendency extremely sad and worrying, even more so since it is not unique to Boost. However, I do not think we can say that Boost *usage* is declining. From the data presented in The C++ Alliance proposal, it looks like the number of Boost downloads is growing, so much so we had to contract a CDN provider to serve them, as well as introduce GitHub downloads. Athough I imagine large portion of these downloads are automated (e.g. CI jobs), even that interpretation speaks in favor of a growing user base (more CI jobs probably means more projects are using Boost). I suppose, it should not be surprising that there are more users than contributors, but I still think it is worth pointing out that Boost popularity is not declining, as it may appear from some online forum comments. 2. Boost asset management. There were several instances of poor management of Boost assets, such as: - The boost.org domain, which was nearly lost to an auction. - The website. The current website is mostly unmaintained, and there is no (public) plan of modernizing it. The new proposed website is rejected by The Boost Foundation and remains "unofficial" at boost.io. - Social media accounts. The official @Boost_Libraries account on X is dormant, and the access to it is restricted from members of The C++ Alliance who have volunteered to maintain its activity. Which resulted in creation of a separate, "unofficial" @BoostLibraries account. - The wowbagger server that is running the current website and mailing lists is outdated and have seen hardware failures that resulted in data loss (as noted in The C++ Alliance proposal). The software stack on the server is also outdated and cannot be easily updated. - The Boost logo, for which, apparently, The Boost Foundation doesn't hold the appropriate license. The duplicate website and X account are especially bad for users, as it causes confusion as to which one is genuine and the true source of information. They are also very similarly named, so much so that one might question their legitimacy. I'd like to point out that the issues with Boost downloads, when we exceeded the free downloads quota, were largely solved with help of The C++ Alliance and The Boost Foundation (specifically, I believe, Sam Darwin and Glen Fernandes). This is an example when the two organizations (or perhaps, individuals thereof) have collaborated to solve the immediate problem. Many thanks to everyone involved. 3. Lack of communication with asset management body. I think, many of Boost community were unaware of the asset management issues listed above until recent discussions on the ML. I personally did not know about the issues with boost.org, data loss on wowbagger and licensing issues for the logo until recently. I believe, some of these issues could have been solved sooner if they were communicated on the ML by The Boost Foundation. Furthermore, even after the issues have become known, there were, depending on the specific asset, little to no communication from The Boost Foundation as to (a) whether the problem is real and (b) what is the proposed plan on addressing it. Basically, The Boost Foundation took a reactive stance in regards to The C++ Alliance actions that it (the Foundation) perceived as hostile. III. Evaluation of The Boost Foundation proposal ================================================ My overall impression of the proposal is that it lacks substance and in some ways is not aligned with Boost traditions. Following is my analysis of how the proposal tackles the stated problem. 1. Boost popularity decline. A significant portion of the proposal is titled "Our Community Values". I'd like to note that this seems to implicate that these values are those of the Boost project community rather than those of The Boost Foundation. This is further reinforced by the contents of the "What we propose" section, which stem from these stated values. I do not believe this implication is correct. In fact, I do not see these values listed anywhere on the www.boost.org website or the "Proposal for a C++ Library Repository Web Site" (https://www.boost.org/users/proposal.pdf) While some of the values listed in the proposal are aligned with the spirit of the Boost project, others are not. In particular, the "Inclusivity" section discusses representation of women in The C++ Alliance staff and the proposed Steering Committee. This is entirely irrelevant for the purpose of Boost asset management and looks like a cheap stab at the opponent. The document then goes on to propose to "make an active effort to get those historically underrepresented to participate". I think, this is an entirely wrong approach to the problem. Boost has never been about representation of women, or any other social category for that matter. The relevant portions of our guidelines are this: A guiding principal is to encourage wide participation and interaction. Get people involved, in newsgroups, mailing lists, as peer reviewers, library contributors and maintainers, and as moderators and webmasters. And, of course, as library users. (https://www.boost.org/users/proposal.pdf) 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. [...] Boost welcomes and thrives on participation from a variety of individuals and organizations. (https://www.boost.org/) Notice that nowhere in these lines specific social groups are mentioned. I'd like to think this is intentional. The only criteria mentioned is talented people willing to contribute their time, ideas, code and effort to various areas of Boost, an open and widely useful collection of C++ libraries. Martians included. As soon as you substitute this criteria of technical merit with inclusivity/representation agenda, you are taking away from the technical quality of the community and bringing in unhealthy atmosphere of inequality. Ultimately, this harms the project as a whole. I find this unacceptable. Another related suggestion made in the proposal is introduction and enforcement of "a strong code of conduct". Also, "make an active effort to improve behavior on the mailing list". The proposal does not go into details as to what the "strong code of conduct" might look like, or in what way the behavior on the mailing list needs to be improved, but given the inclusivity agenda I have to make some uncomfortable assumptions. Specifically, that the suggested code of conduct is intended to promote the agenda and could potentially be used to prosecute those who disagree. I know I have commented on this topic earlier, but I feel compelled to make this part of my review. I find this sort of code of conduct, as well as using it as leverage on people unacceptable. I do not want to see Boost descending into curating people's opinions (let alone their behavior outside Boost), segregation, preferentialism and political infights. I think, our current discussion policy strikes a good balance between defining what's considered unacceptable behavior and leaving enough freedom to keep the discussions vibrant and productive. I don't remember a case when we needed something more strict, and I don't remember us needing to enforce it onto someone either. Lastly in this problem category is the suggestion to "consider adopting a modern communication platform, such as discourse". There was a discussion on this topic on the ML (unfortunately, threading was broken at the time, but you can search by "Replacing the ML with a forum" in the title), which showed a strong preference for ML in the community. I do not think switching to a web forum solution, especially one that does not support threading, would be in the best interest of the community. It may attract more new users, but it will also push away active developers. New users are not necessarily going to replace the maintainers who are going to leave. Personally, I'm not seeing myself switching to a web forum. If the suggestion is not to switch but to bring up a forum *in addition* to the ML, this is also not a good solution, IMO. If the two platforms are independent from each other, this will result in community fragmentation, which I would like to avoid. In particular, this would make review discussions problematic, assuming the review would happen both on forum and ML. I'm not against a forum interface per se, but I think it should integrate with the ML, so that people using both interfaces are able to communicate with each other transparently. Which is something similar to what The C++ Alliance is working on. 2. Boost asset management. I feel that this aspect of the stated problem is not addressed by the proposal nearly at all. Which is disappointing, since I was hoping that this aspect would receive the most attention of The Boost Foundation given the recent communications on the ML and direct requests from the community. The proposal mostly states that The Boost Foundation retains ownership of the assets and undergoes internal organizational changes so that each asset is associated with a given member of the Foundation. While personal responsibility and staff rotation are good, this doesn't really address the issues at hand. For example, what is the proposed resolution with the website? The logo? The wowbagger server? And so on. These questions remain unanswered. 3. Lack of communication with asset management body. Out of the three problem aspects, I got the most positive impression on this one from the proposal. I do like the idea of introducing key officers on the ML, as well as open board meetings. On the latter, I would like to amend so that online attendance should be possible, as not everyone lives near the location of the board headquarter, or wherever the meeting takes place. I would also like to see periodic reports on the ML (e.g. once a quarter) on what was done in the given period, what are the current problems, who is working on them, what was done and what is the plan going forward. I would like to see more active responses from The Boost Foundation on direct requests from the community. Perhaps, set up a public issue tracker so that people are able to report problems and track their progress. This might be as simple as a GitHub project with an issue tracker and a task list (https://docs.github.com/en/get-started/writing-on-github/working-with-advan…) 4. Other thoughts. The proposal suggests "Complete the CMake migration". While I'm not opposed to continued work on CMake support, I do not think it is The Boost Foundation's role to declare tasks like this. It is a decision made by the Boost community, and the work is done by library maintainers. Same for "Consider putting the monolithic distribution in maintenance mode and require new libraries to be self contained". This is not a decision to be made by The Boost Foundation; it must be discussed on the ML first. To this end, I do not think requiring all new libraries to be self-contained (that is, not have any dependencies) is realistic or a worthy goal to pursuit anyway. IV. Evaluation of The C++ Alliance proposal =========================================== My overall impression is that The C++ Alliance proposal is more substantial and comprehensive, which I like. 1. Boost popularity decline. The proposal describes the work that The C++ Alliance has been doing to improve participation in the project. I'm assuming, the proposal implies that the work will continue if the proposal is accepted. In particular, these items were mentioned: - The new, "refreshed" website - A more active X account, with a new image art design - A C++ Slack workspace, which is used for Boost-related chat-style communications - Updated mailman+hyperkitty ML backend in development which will offer a web forum-like interface for the ML - Marketing materials and merchandise distributed on CppCon Those are all very welcome endeavors, especially those which improve accessibility and communication between people. I think, improved communication is a key element of improving public image of Boost and bringing in new contributors - perhaps, more important than the refreshed "looks". As I said in the problem statement section, I think the most deterring factor for potential library contributors is the necessity to undergo a Boost review and then maintain the submitted library. Some developers who target the C++ standard perceive Boost as an unnecessary effort that can be avoided. I'm not sure the above measures will help overcome this perception, but at least they should make Boost more accessible to contributors offering help in other ways, e.g. by providing user feedback and patches. I think, the only party who can improve the situation with the straight-to-standard libraries is WG21, which is out of our hands. What Boost can do is maintain the high quality bar, even if it means less volunteers than we'd like. Besides attracting more volunteers, The C++ Alliance is sponsoring development and employ engineers working on Boost. On one hand, this makes things done and provides another steady flow of contributions, especially in the unpopular areas, like documentation updates. On the other hand, Boost is increasingly becoming controlled by The C++ Alliance, where the majority of roles are fulfilled by the Alliance's employees. There is a saying in my country that can be translated as "the one who dines a girl also dances her", which basically means the one who does the work should also reap the benefits from it. I suppose, it's fitting, but I would still prefer Boost to remain an independent project. This is actually my biggest concern with The C++ Alliance proposal - it further increases control of the Alliance over Boost. 2. Boost asset management. The core of the proposal is to transfer ownership of the Boost assets to The C++ Alliance, to be managed on behalf of the newly created Steering Committee, which is supposed to be formed from Boost community members. In the past, The C++ Alliance have demonstrated that they are willing and able to solve issues with Boost infrastructure and assets. Specifically, to address the aging website, a new one was (and still is) developed, to fix archive downloads a CDN provider was contracted and so on. And although I have reservations about the new logo usage terms and looks, it also exists as a solution to the licensing issues with the old logo. So clearly, this demonstrates that The C++ Alliance is capable of maintaining Boost assets in good condition. However, The C++ Alliance is still an external entity, which is funded by a single individual, Vinnie Falco. This poses risks associated with possible funding issues and changing directional vision for The C++ Alliance and by extension, Boost. The first risk may be mitigated by finding other sources of income, such as donations and merchandise distribution, which, I believe, was the source of funding until now, with The Boost Foundation. The second risk is supposed to be mitigated by introduction of the new Steering Committee, which should represent the Boost project community and define "the technical, artistic and philanthropic direction" of the project. This last part I would like to investigate further. In the Fiscal Sponsorship Agreement (FSA) draft in Appendix 1 of the proposal, two Committees are mentioned. The Current Committee, as I understand it, is sort of a bootstrap for the Steering Committee, and its members are listed in the FSA. I am not sure why the Current Committee is needed, and why is it not possible to form the Steering Committee from the start and only reference it in the FSA. Maybe there's some legal reason to it that I'm not aware of, but it looks like a superfluous entity to me. Another point is that in the list of members of the Current Committee, two of the three members are also members of The C++ Alliance. The FSA does not outline the decision making process in the Current Committee, but strangely does so for the Steering Committee: All decisions of the Steering Committee shall be made by simple majority. This raises two issues. First, if the Current Committee's decision making process is the same then The C++ Alliance has the majority vote in the Committee. I'm not questioning the integrity of the proposed members of the Current Committee, I have nothing but respect for each of the individuals, but I would still prefer if The C++ Alliance didn't have the deciding majority on the Committee. Someone on the ML proposed to include Glen Fernandes and Peter Dimov in the Current Committee, and I support this nomination. Furthermore, I would like the similar problem with the Steering Committee to be mitigated as well. One option is to amend the mechanism for picking members to restrict The C++ Alliance presence in the Committee to less than majority of members. Another option might be to involve the community in the member election, e.g. by holding a vote for candidates. In any case, the goal is to ensure that the Steering Committee represents the Boost project community rather than The C++ Alliance. The second issue is that I find it surprising that FSA is defining the decision making process in the Steering Committee in the first place. It would seem to me that the Steering Committee should have its own bylaws and should decide on how it operates internally, and that has nothing to do with FSA. As long as the Steering Committee's decisions go in line with the FSA, it should not matter how these decisions are made. I'd like to note that I have no preference for the Steering Committee's decision making process; my issue is not with the "by simple majority" part. Although there should be a tie breaker, if the number of members is even. Another thing that bothers me is that The C++ Alliance reserves the right to appoint members of the Steering Committee to bring its size up to three members. I realize that this is supposed to be an emergency plan of sorts, but it seems wrong that The C++ Alliance is making the pick. It would seem, the self-preservation plan should be in the Steering Committee's bylaws, and The C++ Alliance should not be acting in its place. Lastly on this topic, the last part of this sentence seems controversial: Authority to manage the technical, artistic and philanthropic direction of the Project and the program activities of the Project is delegated to the Steering Committee as defined in §6, subject at all times to the direction and control of Alliance’s Board of Directors. It might be my poor understanding of the legal wording, but it looks like this suggests that the Steering Committee is operating under control of The C++ Alliance's Board, which contradicts with the first part of the sentence. Either the Committee decides on the Project's direction, or it is controlled by the Alliance and then it is the Alliance who actually decides on the Project direction. My preference would be the former, in which case this sentence should probably be amended. I would like to comment on the section 8 of the FSA, "Termination". I'm not familiar with the US laws, but do the timeouts for searching for a Successor allow for registering a new 501(c)(3) entity for the purpose of passing the assets to it? The way the section 8.d "Termination Without a Successor" is phrased implies that the assets could potentially be destroyed or otherwise made permanently unavailable to the Project. I'm wondering if there is a better solution, like creating a new non-profit for the purpose of passing it the assets. I admit I'm completely clueless in this domain, I'm just looking if the Termination terms could be improved for Boost. Especially, in the case if The C++ Alliance is no longer able to fulfill its sponsorship. 3. Lack of communication with asset management body. The C++ Alliance members already post periodic reports about the Alliance's activity, and I hope this initiative will continue if the proposal is accepted. Alliance's members are also active on the ML, which is very welcome. So, in the communication department The C++ Alliance has a good track record already. One instance where the communication did fail was the attempt to purchase the boost.org domain from the Dawes estate. I feel, this matter could have been handled better. At the very least, the community could have been made aware of the situation with the domain name and the planned resolution. I can understand how this buyout attempt could be interpreted as a hostile action by The Boost Foundation, and The C++ Alliance (and Vinnie Falco in particular) should have known this would be the outcome. If the proposal is accepted, I would like to ask the Alliance to be transparent about their planned and ongoing activities wrt. Boost assets to avoid situations like this in the future. Doing things like buying the domain name behind everyone's back is not acceptable. In fact, this should be straight prohibited by the terms of FSA, as the Alliance is supposed to act on behalf of the Steering Committee when it comes to Boost assets. Lastly, the suggestion I made in The Boost Foundation proposal review regarding GitHub tasks and issue tracker might be relevant here as well. V. Conclusion ============= Given that The Boost Foundation proposal lacks substance on the asset management part, leaving many questions unanswered, and is taking what I consider a completely unacceptable direction on the community engagement front, I vote to REJECT The Boost Foundation proposal. I understand there likely won't be a second round of review, but if there was, I would have liked to see a more constructive proposal that is more focused on the problems at hand and proposed concrete solutions for them. Where the opponent offers a solution, you should be offering yours instead of stabbing the opponent. I find The C++ Alliance proposal closer to what I would like to see in Boost. On The C++ Alliance proposal I vote ACCEPT WITH CONDITIONS with a single condition being to ensure that the newly created Steering Committee is able to make decisions and operate independently from any possible leverage from The C++ Alliance, in the interests of the Boost project. The specific concerns I have on this front are described in the proposal review. I'd like to thank The Boost Foundation and The C++ Alliance for putting forth their proposals. I'm sure they put a lot of work in it. And I'd like to thank Glen Fernandes for managing this review, which surely is a difficult and responsible task. And if you read this far, thanks for your time and patience. :)

4 6