On Tue, Sep 3, 2024 at 10:00 AM Andrzej Krzemienski wrote:

wt., 3 wrz 2024 o 12:34 Glen Fernandes napisał(a):

...

Just to be clear, you want to know what role each of the individual directors on the Boost Foundation board have in the Beman Project? Or the role that the Boost Foundation plans to play in the Beman Project?

Oh, I mean the latter. The Boost Foundation as a body.

Andrzej, understood. A response from the chair of the Boost Foundation is forthcoming. Glen

czw., 5 wrz 2024 o 23:22 Kristen Shaker napisał(a):

Hi Andrzej,

Boost has always and still is a breeding ground for high-quality, peer reviewed C++ libraries. Some of these libraries made it to the standard and some of them were never intended or appropriate for the standard. Boost.Python, which is a C++/Python interop library, is a good example.

We wanted to create a dedicated space for users to test and give feedback on all libraries proposed for standardization - not just those coming from Boost. Without Beman, the C++ community has no way to play around with most of what is being proposed.

Both of these projects are valuable. They are both part of The Boost Foundations mission to "develop high quality, expert reviewed, legally unencumbered, open-source libraries" and "inspire standard enhancements" Both can live under the same organizational umbrella. The Boost Foundation is committed to the success of both projects.

Warm Regards, Kristen

Kristen, thank you for this statement. I would like to dig further on this part: We wanted to create a dedicated space for users to test and give feedback

on all libraries proposed for standardization - not just those coming from Boost. Without Beman, the C++ community has no way to play around with most of what is being proposed.

Six months earlier I would think that authors of the proposals targeting LEWG would be encouraged to propose their library into Boost. There, to undergo the scrutiny of the Boost Review process, and then to have a released library that users can use and report their feedback on. Why encourage people to join a new project rather than use Boost that I would think was designed for this purpose? I know that this question departs from the topic of Asset Stewardship, but it is about the future of Boost, and therefore related. If people, especially (but not only) those on the Boost Foundation Board, think Boost is unfit for this purpose, I would like to know why. Maybe this can be fixed. Regards, &rzej;

On Thu, Sep 5, 2024 at 12:48 AM Glen Fernandes via Boost < boost@lists.boost.org> wrote:

...

On Tue, Sep 3, 2024 at 10:00 AM Andrzej Krzemienski wrote:

...

wt., 3 wrz 2024 o 12:34 Glen Fernandes napisał(a):

...

Just to be clear, you want to know what role each of the individual directors on the Boost Foundation board have in the Beman Project? Or the role that the Boost Foundation plans to play in the Beman Project?

Oh, I mean the latter. The Boost Foundation as a body.

Andrzej, understood. A response from the chair of the Boost Foundation is forthcoming.

Glen

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On Tue, Sep 10, 2024 at 2:49 AM Andrzej Krzemienski wrote:

I must say that I am surprised that there was no reply to this question from the individual directors of the Boost Foundation Board. I can see that four members of the Board are actively participating in the Beman project. I would have expected that they gave their input on the concerns I expressed.

In the context of the Boost Asset Stewardship Review, the Boost Foundation also has a request from the Boost Developers Community, so I would think it is in the best interest of the Foundation members to participate in this review, hear the expressed questions and concerns and reply to them.

Let me ask again, mostly the people that promote the Beman project, why do you think Boost is unfit for the purpose of incubating libraries that target the Standard Library?

Hi Andrzej, If not sooner, I should have an answer that represents the Beman project leadership's thoughts on this, latest tomorrow at 3pm EST after the Boost Foundation monthly meeting. I also want to confirm that your inquiry is not independent of the Asset Stewardship review. i.e. It matters if the Boost Foundation chooses to support another initiative (or the Beman project specifically). Thanks, Glen

On Tue, Sep 10, 2024 at 1:50 PM Andrzej Krzemienski via Boost wrote:

I have always thought that Boost was conceived to help create high-quality libraries, with the purpose in mind that they would be good candidates for standardization. The quality would have been achieved through the thorough Boost Review process, and then through collecting user (commercial and private) experience. Boost evidently fulfilled this role. Boost libraries are still proposed for standardization: Boost.Static_vector and Boost.ASIO.

These kinds of additions are pretty rare. Compare static_vector, flat_map, and the modification of optional to have the T& sepcialization to the number of library features added in the same time period that did *not* come from Boost. Also, all of those things are "old" in some sense. None of them was added in the last 10 years.

I would expect that the Boost Foundation Board members present at WG21 (the ISO/IEC C++ Standards Committee) meetings would encourage the proposal authors to take the Boost path. Do they?

Sure. I've tried, and *hard*. Tony Van Eerd and David Sankel are also two regulars who ask, "Why isn't this a Boost library?" There are almost never any takers. It comes down to this: 1) It's another hurdle to jump. Getting something through committee review means handing off maintenance to library implementers. Going through Boost first means dealing with yet another specific process (that's a lot by itself), but also incurring a long-lived maintenance task as well. 2) Boost is not a very welcoming place. I have had at least one WG21 member show up here, at my behest, be treated "quite rudely" by his lights, and then promptly leave, never to return. I have heard many people say the same thing at conferences over the years (so, not WG21 folks necessarily). And before you debate whether this is a justified reaction, or say these people are thin-skinned weenies or whatever, know that such a debate does not ultimately matter. If people feel unwelcome or that interacting with this list is futile, they won't bother. 3) The tools suck. Boost build and our doc chain are great once you have them set up, but are impenetrable to newcomers. They are non-standard, which is unavoidable for a doc chain (there is no de facto standard), but odd and disappointing when it comes to build (the world has standardized on CMake, for better or worse). 4) The one time I managed to cajole someone into doing a Boost review, it was rejected because people didn't see the point of it. I'm still not sure why that was. It had a point, is quite useful, and is now in the standard. At the time of the review, it was clear that this was probably going into C++ with or without Boost, and people also did not care to have it in Boost for that reason. One kind of Boost library content is implementations of things that are in the standard that might not yet be in your implementation. This was a chance to influence the direction of a standard library entity, and people did not see that opportunity for influence to be worth their time. That last point is very important. #4 is not a criticism, so much as pointing out a very different orientation of Boost vs. WG21. There's nothing wrong with this. It does however indicate that a new project, focused exclusively on road-testing new libraries bound for the standard, should be created. That project is Beman.

Of course, the proposal authors may not want to do it for valid reasons. In that case, I would expect Boost Foundation Board members present at WG21 meetings to collect these reasons and report them to the Boost community, e.g., via the Boost Developers mailing list. Is this happening?

I've said these things at various times, on the list and off, but what I wrote above is the first time I've tried to summarize all the issues in one place.

I hear from my colleagues in WG21 that it is Boost leaders that proposed the Beman project because they do not think Boost works well. This is more like a rumor, so one can hardly build their position based on this, but it adds to the impression that there is a subset of the Boost Foundation Board members who do not believe Boost is capable of fulfilling the mission of incubating the libraries intended for standardization.

This is not accurate. I think the consensus among Beman participants is that Boost should do what Boost does well -- peer reviewed C++ libraries -- and Beman should do its thing -- provide a testing ground and distribution mechanism not for C++ libraries in general, but for C++ standard library entities *only*. These are very different aims.

They may be right. But in that case, I think the Boost community deserves to hear the reasons.

My impression might be wrong and unfair, therefore I would like the people to respond to this, and possibly clear things up.

Hopefully what I wrote answers your questions.

I know this is long and unstructured, so thank you for reading till the end. I hope I managed to get across why the question about the Beman Project is relevant in the context of the Boost Asset Stewardship Review.

Not at all. Thanks for bringing this up. Zach

El 11/09/2024 a las 12:41, Zach Laine via Boost escribió:

These kinds of additions are pretty rare. Compare static_vector, flat_map, and the modification of optional to have the T& sepcialization to the number of library features added in the same time period that did *not* come from Boost. Also, all of those things are "old" in some sense. None of them was added in the last 10 years.

I'm not following the static_vector standardization, but in the flat_map case, the standardized std::flat_map is significantly different (split storage of keys and values) from the boost implementation, so I wouldn't say boost::container::flat_map is the base of std::flat_map (and IMHO reusing the same name will be a problem for C++ users).

3) The tools suck. Boost build and our doc chain are great once you have them set up, but are impenetrable to newcomers. They are non-standard, which is unavoidable for a doc chain (there is no de facto standard), but odd and disappointing when it comes to build (the world has standardized on CMake, for better or worse).

The way things work in Boost is doing the work. It's a federation of libraries so even if the Foundation might have a vision, the Foundation can only encourage or look for contributors that will do the work. Modifying 160+ libraries is no joke. When a project scales, changing direction is not easy/feasible, especially if it's a paid work.

That last point is very important. #4 is not a criticism, so much as pointing out a very different orientation of Boost vs. WG21. There's nothing wrong with this. It does however indicate that a new project, focused exclusively on road-testing new libraries bound for the standard, should be created. That project is Beman.

That's why I mentioned in my review that both projects should cooperate. Beman could take a Boost utility/library for the standard and Boost could take a Beman library (regardless of its inclusion in the final draft) and expand/improve it.

This is not accurate. I think the consensus among Beman participants is that Boost should do what Boost does well -- peer reviewed C++ libraries -- and Beman should do its thing -- provide a testing ground and distribution mechanism not for C++ libraries in general, but for C++ standard library entities *only*. These are very different aims.

I agree. Best, Ion

Am 11.09.2024 um 13:42 schrieb Boris Kolpackov via Boost:

The "world" has decidedly not standardize on CMake. If anything, it uses CMake as a lesson in what not to do: if you look at the recent crop of build systems (Cargo, Zig build, buck2) -- none of them are meta build systems. The problem I have with "pure" build systems is that they don't integrate well with IDEs. I heavily rely on IDE features such das "GoTo declaration" (often better than reading docs), auto-completion etc. and CMake fills this role by not by reinventing the wheel but working with existing tools. I can have a Visual Studio project when working on/for Windows or a compile_commands.json when working on Linux e.g. with VS Code or any ++ language server supporting that.

On Mon, Sep 16, 2024 at 1:18 AM Thomas Fowlery via Boost < boost@lists.boost.org> wrote:

This is true for Visual Studio, but any build system should be able to generate compile_commands.json for clangd to use. It seems like even B2 supports it now:

https://github.com/boostorg/build/commit/fbb7fb175a78f8b39dcd4714d06c910da8e...

So meta build systems are definitely not a necessity :)

This is true but only as a technicality. CMake is basically the de facto standard for most OSS projects. It's easier to probably enumerate the OSS projects that _don't_ use CMake. - Christian

пн, 16 сент. 2024 г. в 18:31, Vinnie Falco via Boost :

I wouldn't be so sure about that. From the Jetbrains build system survey [1]:

While I also maintain that CMake's popularity is not that overwhelming as many people think, that's a survey of JetBrain customers, not necessarily OSS projects.

On Mon, Sep 16, 2024 at 9:23 AM Peter Dimov via Boost wrote:

As a serendipitous data point, I was just made aware that the nice folks behind Compiler Explorer have enabled linking to compiled Boost libraries:

https://godbolt.org/z/1fcoKra8n

They build Boost with CMake and use the Github CMake release archives.

In a similar vein, vcpkg actually did the same thing: switched their package files from using b2 to CMake. In these kinds of cases, I think it's just that most projects can handle CMake projects in some capacity whereas b2 is a strong outlier so when applicable, it gets eschewed. - Christian

On Tue, Sep 17, 2024 at 11:48 AM Nelson, Erik - 2 wrote:

As a boost user, I've always appreciated that Boost can be bootstrapped directly from the downloaded sources... no need to install third-party tools on my multiple platforms that I don't have admin access to.

As far as I'm aware, you don't need admin access to "install" vcpkg or Conan. I put "install" in quotes here because technically, I just `git clone vcpkg.git` and use it like that, so to me this isn't really "installing" it. If you can download Boost source and bootstrap b2, I'd imagine you could just clone vcpkg as well but I'm not aware of your specifics. But fwiw, nothing I do usually involves sudo on my machine. - Christian

śr., 11 wrz 2024 o 07:41 Zach Laine via Boost napisał(a):

On Tue, Sep 10, 2024 at 1:50 PM Andrzej Krzemienski via Boost wrote:

...

I have always thought that Boost was conceived to help create

...

libraries, with the purpose in mind that they would be good candidates for standardization. The quality would have been achieved through the

high-quality thorough

...

Boost Review process, and then through collecting user (commercial and private) experience. Boost evidently fulfilled this role. Boost libraries are still proposed for standardization: Boost.Static_vector and Boost.ASIO.

These kinds of additions are pretty rare. Compare static_vector, flat_map, and the modification of optional to have the T& sepcialization to the number of library features added in the same time period that did *not* come from Boost. Also, all of those things are "old" in some sense. None of them was added in the last 10 years.

...

I would expect that the Boost Foundation Board members present at WG21 (the ISO/IEC C++ Standards Committee) meetings would encourage the proposal authors to take the Boost path. Do they?

Sure. I've tried, and *hard*. Tony Van Eerd and David Sankel are also two regulars who ask, "Why isn't this a Boost library?" There are almost never any takers. It comes down to this:

1) It's another hurdle to jump. Getting something through committee review means handing off maintenance to library implementers. Going through Boost first means dealing with yet another specific process (that's a lot by itself), but also incurring a long-lived maintenance task as well.

2) Boost is not a very welcoming place. I have had at least one WG21 member show up here, at my behest, be treated "quite rudely" by his lights, and then promptly leave, never to return. I have heard many people say the same thing at conferences over the years (so, not WG21 folks necessarily). And before you debate whether this is a justified reaction, or say these people are thin-skinned weenies or whatever, know that such a debate does not ultimately matter. If people feel unwelcome or that interacting with this list is futile, they won't bother.

3) The tools suck. Boost build and our doc chain are great once you have them set up, but are impenetrable to newcomers. They are non-standard, which is unavoidable for a doc chain (there is no de facto standard), but odd and disappointing when it comes to build (the world has standardized on CMake, for better or worse).

4) The one time I managed to cajole someone into doing a Boost review, it was rejected because people didn't see the point of it. I'm still not sure why that was. It had a point, is quite useful, and is now in the standard. At the time of the review, it was clear that this was probably going into C++ with or without Boost, and people also did not care to have it in Boost for that reason. One kind of Boost library content is implementations of things that are in the standard that might not yet be in your implementation. This was a chance to influence the direction of a standard library entity, and people did not see that opportunity for influence to be worth their time.

That last point is very important. #4 is not a criticism, so much as pointing out a very different orientation of Boost vs. WG21. There's nothing wrong with this. It does however indicate that a new project, focused exclusively on road-testing new libraries bound for the standard, should be created. That project is Beman.

...

Of course, the proposal authors may not want to do it for valid reasons. In that case, I would expect Boost Foundation Board members present at WG21 meetings to collect these reasons and report them to the Boost community, e.g., via the Boost Developers mailing list. Is this happening?

I've said these things at various times, on the list and off, but what I wrote above is the first time I've tried to summarize all the issues in one place.

...

I hear from my colleagues in WG21 that it is Boost leaders that proposed the Beman project because they do not think Boost works well. This is more like a rumor, so one can hardly build their position based on this, but it adds to the impression that there is a subset of the Boost Foundation Board members who do not believe Boost is capable of fulfilling the mission of incubating the libraries intended for standardization.

This is not accurate. I think the consensus among Beman participants is that Boost should do what Boost does well -- peer reviewed C++ libraries -- and Beman should do its thing -- provide a testing ground and distribution mechanism not for C++ libraries in general, but for C++ standard library entities *only*. These are very different aims.

...

They may be right. But in that case, I think the Boost community deserves to hear the reasons.

My impression might be wrong and unfair, therefore I would like the people to respond to this, and possibly clear things up.

Hopefully what I wrote answers your questions.

Indeed it does! Thanks Zach for this input. This is exactly the kind of information I was hoping to get. This gives us something to work on. I take it seriously that Boost is perceived as an unwelcoming environment. Also, some things that you say seem to correspond with Vinnie's observation. If one feels one got a green light from LEWG that one's library will be accepted into STD, the motivation for putting it into Boost diminishes. Here, I do not think we will be able to do much. Once again, Thank you for your thoughtful input. Regards, &rzej;

...

I know this is long and unstructured, so thank you for reading till the end. I hope I managed to get across why the question about the Beman Project is relevant in the context of the Boost Asset Stewardship Review.

Not at all. Thanks for bringing this up.

Zach

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

...

The Boost Foundation proposal states that "...success in today’s society requires a strong and enforced Code of Conduct." It goes on to propose

#1 that the incorporation and enforcement of a strong code of conduct will "increase engagement and trust within Boost."

...

Q. Which Code of Conduct does the Boost Foundation believe is best for Boost, is it this one: https://github.com/beman-project/beman/blob/main/docs/CODE_OF_CONDUCT.md ?

That's a good one, but there are others.

...

Q. What specific problems does the Code of Conduct intend to solve (perhaps with examples)?

A code of conduct does nothing without enforcement, but the combination of the two will help solve problems. Several very strong and capable engineers have approached the Boost Foundation saying they will not participate in Boost without an enforced code of conduct. Some do this on general principle, and others because they actively don't feel comfortable participating in Boost spaces as they are currently run. There have been many studies showing uncivil workplace behavior causes poor performance, attrition, and reputational damage. There is every reason to believe this carries over to online communities as well.

Q. How does engagement generally increase when incorporating an enforced Code of Conduct?

In Boost's case, this would take a while. Trust needs to be built up in the process and when people feel safe enough, they'll start joining in.

...

Q. If there are potential volunteers waiting for a Code of Conduct to begin contributing, what specifically is holding them back from contributing now?

As mentioned above, there are folks who don't want to subject themselves to what they perceive to be an uncivil environment. A code of conduct is necessary, but not sufficient to convince these people that Boost will be a welcoming and emotionally healthy place to participate in. I'd like to echo Zach's point here. If outside individuals deem the community to be unwelcoming, it doesn't serve anyone to have a debate about whether they should be "thicker skinned." People who feel unwelcome will not participate.

...

Q. What is the meaning of "trust" in the context of the proposal? Q. What problems does the current level of "trust within Boost" bring, and how does a Code of Conduct solve them?

An enforced code of conduct would show individuals who have historically felt that Boost is an unwelcoming environment that it is starting to trend positively towards being more welcoming. This, over time, will increase engagement and encourage outside participation in the community.

#2

...

Given that we just released Boost 1.86.0 a couple of weeks ago: Why aren't Boost release announcements being posted to X at https://x.com/Boost_Libraries ?

No one from the Boost community has offered wording for a post. The board is more than happy to make posts upon request.

#3

...

If the community accepts the Boost Foundation's proposal as currently written, would the Code of Conduct you institute prevent someone like Arthur O'Dwyer from participating on the mailing lists?

The code of conduct has no provisions for proactively banning anyone. It is a process whereby someone can raise a concern to the code of conduct team, an investigation will be done, and a decision will be made.

#4

...

Is it possible to rename a 501(c)(3) non-profit? Would the Boost Foundation consider renaming?

Yes, it is possible, and yes it is something we would consider.

#5 (several along the same lines)

...

What is the status of the domain transfer?

I believe I covered this in an earlier email. It's happening. It will just take time.

...

What is the risk the transfer is not possible and the domain will lapse and go to auction? Is there a signed agreement in place?

Low risk. Yes, there is a signed agreement in place.

...

What is the breakdown of funding the Boost Foundation gives to the Beman

#6 (several about the Beman project) project vs the Boost libraries?

Discounting Boost Foundation donations earmarked for the Beman project, the ratio of spending on the Boost project vs. the Beman project is 284:1.

...

Does the Boost Foundation steer policy in the Beman project or just pay the bills like it does for Boost?

The Boost Foundation is responsible for breaking community deadlock for the Boost project, but it does not do this for the Beman project. For the Beman project, it pays a small amount towards operating expenses. Warm Regards, Kristen On Wed, Sep 11, 2024 at 9:10 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

On Wed, Sep 11, 2024 at 6:04 AM Andrzej Krzemienski via Boost wrote:

...

If one feels one got a green light from LEWG that one's library will be accepted into STD, the motivation for putting it into Boost diminishes. Here, I do not think we will be able to do much.

Inbal Levi is a member of the Boost Foundation Board of Directors. She is also the chair of LEWG. Every library-only proposal for C++ (including std::execution) must go through LEWG first. LEWG could simply adopt as a policy, that any library-only proposal must already be published as a library, for a minimum period of time, and having acquired users and integration in other public projects. This doesn't mean it has to be accepted into Boost first, although that is an option.

The "green light from LEWG" could be changed to a red light. My personal opinion is that if the only thing that LEWG did was to reject all pure library proposals for ten years, C++ would be improved.

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

czw., 12 wrz 2024 o 19:08 Kristen Shaker via Boost napisał(a):

...

#1

...

The Boost Foundation proposal states that "...success in today’s

society

...

requires a strong and enforced Code of Conduct." It goes on to propose that the incorporation and enforcement of a strong code of conduct will "increase engagement and trust within Boost."

...

Q. Which Code of Conduct does the Boost Foundation believe is best for Boost, is it this one: https://github.com/beman-project/beman/blob/main/docs/CODE_OF_CONDUCT.md ?

That's a good one, but there are others.

...

...

Q. What specific problems does the Code of Conduct intend to solve (perhaps with examples)?

A code of conduct does nothing without enforcement, but the combination of the two will help solve problems.

Several very strong and capable engineers have approached the Boost Foundation saying they will not participate in Boost without an enforced code of conduct. Some do this on general principle, and others because they actively don't feel comfortable participating in Boost spaces as they are currently run.

There have been many studies showing uncivil workplace behavior causes poor performance, attrition, and reputational damage. There is every reason to believe this carries over to online communities as well.

...

Q. How does engagement generally increase when incorporating an enforced Code of Conduct?

In Boost's case, this would take a while. Trust needs to be built up in the process and when people feel safe enough, they'll start joining in.

...

...

Q. If there are potential volunteers waiting for a Code of Conduct to begin contributing, what specifically is holding them back from contributing now?

As mentioned above, there are folks who don't want to subject themselves to what they perceive to be an uncivil environment. A code of conduct is necessary, but not sufficient to convince these people that Boost will be a welcoming and emotionally healthy place to participate in. I'd like to echo Zach's point here. If outside individuals deem the community to be unwelcoming, it doesn't serve anyone to have a debate about whether they should be "thicker skinned." People who feel unwelcome will not participate.

...

...

Q. What is the meaning of "trust" in the context of the proposal? Q. What problems does the current level of "trust within Boost" bring, and how does a Code of Conduct solve them?

An enforced code of conduct would show individuals who have historically felt that Boost is an unwelcoming environment that it is starting to trend positively towards being more welcoming. This, over time, will increase engagement and encourage outside participation in the community.

...

#2

...

Given that we just released Boost 1.86.0 a couple of weeks ago: Why aren't Boost release announcements being posted to X at https://x.com/Boost_Libraries ?

No one from the Boost community has offered wording for a post. The board is more than happy to make posts upon request.

...

#3

...

If the community accepts the Boost Foundation's proposal as currently written, would the Code of Conduct you institute prevent someone like Arthur O'Dwyer from participating on the mailing lists?

The code of conduct has no provisions for proactively banning anyone. It is a process whereby someone can raise a concern to the code of conduct team, an investigation will be done, and a decision will be made.

...

#4

...

Is it possible to rename a 501(c)(3) non-profit? Would the Boost Foundation consider renaming?

Yes, it is possible, and yes it is something we would consider.

...

#5 (several along the same lines)

...

What is the status of the domain transfer?

I believe I covered this in an earlier email. It's happening. It will just take time.

...

...

What is the risk the transfer is not possible and the domain will lapse and go to auction? Is there a signed agreement in place?

Low risk. Yes, there is a signed agreement in place.

...

...

What is the breakdown of funding the Boost Foundation gives to the Beman

#6 (several about the Beman project) project vs the Boost libraries?

Discounting Boost Foundation donations earmarked for the Beman project, the ratio of spending on the Boost project vs. the Beman project is 284:1.

...

...

Does the Boost Foundation steer policy in the Beman project or just pay the bills like it does for Boost?

The Boost Foundation is responsible for breaking community deadlock for the Boost project, but it does not do this for the Beman project. For the Beman project, it pays a small amount towards operating expenses.

Warm Regards, Kristen

On Wed, Sep 11, 2024 at 9:10 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Wed, Sep 11, 2024 at 6:04 AM Andrzej Krzemienski via Boost wrote:

...

If one feels one got a green light from LEWG that one's library will be accepted into STD, the motivation for putting it into Boost diminishes. Here, I do not think we will be able to do much.

Inbal Levi is a member of the Boost Foundation Board of Directors. She is also the chair of LEWG. Every library-only proposal for C++ (including std::execution) must go through LEWG first. LEWG could simply adopt as a policy, that any library-only proposal must already be published as a library, for a minimum period of time, and having acquired users and integration in other public projects. This doesn't mean it has to be accepted into Boost first, although that is an option.

The "green light from LEWG" could be changed to a red light. My personal opinion is that if the only thing that LEWG did was to reject all pure library proposals for ten years, C++ would be improved.

Kristen, I am missing some context. It looks like you are answering somebody's questions. Whose questions are they? Regards, &rzej;

Thanks

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

czw., 12 wrz 2024 o 19:08 Kristen Shaker via Boost napisał(a):

...

#1

...

The Boost Foundation proposal states that "...success in today’s

society

...

requires a strong and enforced Code of Conduct." It goes on to propose that the incorporation and enforcement of a strong code of conduct will "increase engagement and trust within Boost."

...

Q. Which Code of Conduct does the Boost Foundation believe is best for Boost, is it this one: https://github.com/beman-project/beman/blob/main/docs/CODE_OF_CONDUCT.md ?

That's a good one, but there are others.

...

...

Q. What specific problems does the Code of Conduct intend to solve (perhaps with examples)?

A code of conduct does nothing without enforcement, but the combination of the two will help solve problems.

Several very strong and capable engineers have approached the Boost Foundation saying they will not participate in Boost without an enforced code of conduct. Some do this on general principle, and others because they actively don't feel comfortable participating in Boost spaces as they are currently run.

There have been many studies showing uncivil workplace behavior causes poor performance, attrition, and reputational damage. There is every reason to believe this carries over to online communities as well.

In a similar vein, the Foundation's counter-proposal proposes: Make an active effort to improve behavior on the mailing list In order to help me understand this, could you give some examples of the behavior on the mailing list that you feel is in need of improvement? The above characterization is so different from my many-year experience with the list. Regards, &rzej;

...

Q. How does engagement generally increase when incorporating an enforced Code of Conduct?

In Boost's case, this would take a while. Trust needs to be built up in the process and when people feel safe enough, they'll start joining in.

...

...

Q. If there are potential volunteers waiting for a Code of Conduct to begin contributing, what specifically is holding them back from contributing now?

As mentioned above, there are folks who don't want to subject themselves to what they perceive to be an uncivil environment. A code of conduct is necessary, but not sufficient to convince these people that Boost will be a welcoming and emotionally healthy place to participate in. I'd like to echo Zach's point here. If outside individuals deem the community to be unwelcoming, it doesn't serve anyone to have a debate about whether they should be "thicker skinned." People who feel unwelcome will not participate.

...

...

Q. What is the meaning of "trust" in the context of the proposal? Q. What problems does the current level of "trust within Boost" bring, and how does a Code of Conduct solve them?

An enforced code of conduct would show individuals who have historically felt that Boost is an unwelcoming environment that it is starting to trend positively towards being more welcoming. This, over time, will increase engagement and encourage outside participation in the community.

...

#2

...

Given that we just released Boost 1.86.0 a couple of weeks ago: Why aren't Boost release announcements being posted to X at https://x.com/Boost_Libraries ?

No one from the Boost community has offered wording for a post. The board is more than happy to make posts upon request.

...

#3

...

If the community accepts the Boost Foundation's proposal as currently written, would the Code of Conduct you institute prevent someone like Arthur O'Dwyer from participating on the mailing lists?

The code of conduct has no provisions for proactively banning anyone. It is a process whereby someone can raise a concern to the code of conduct team, an investigation will be done, and a decision will be made.

...

#4

...

Is it possible to rename a 501(c)(3) non-profit? Would the Boost Foundation consider renaming?

Yes, it is possible, and yes it is something we would consider.

...

#5 (several along the same lines)

...

What is the status of the domain transfer?

I believe I covered this in an earlier email. It's happening. It will just take time.

...

...

What is the risk the transfer is not possible and the domain will lapse and go to auction? Is there a signed agreement in place?

Low risk. Yes, there is a signed agreement in place.

...

...

What is the breakdown of funding the Boost Foundation gives to the Beman

#6 (several about the Beman project) project vs the Boost libraries?

Discounting Boost Foundation donations earmarked for the Beman project, the ratio of spending on the Boost project vs. the Beman project is 284:1.

...

...

Does the Boost Foundation steer policy in the Beman project or just pay the bills like it does for Boost?

The Boost Foundation is responsible for breaking community deadlock for the Boost project, but it does not do this for the Beman project. For the Beman project, it pays a small amount towards operating expenses.

Warm Regards, Kristen

On Wed, Sep 11, 2024 at 9:10 AM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

On Wed, Sep 11, 2024 at 6:04 AM Andrzej Krzemienski via Boost wrote:

...

If one feels one got a green light from LEWG that one's library will be accepted into STD, the motivation for putting it into Boost diminishes. Here, I do not think we will be able to do much.

Inbal Levi is a member of the Boost Foundation Board of Directors. She is also the chair of LEWG. Every library-only proposal for C++ (including std::execution) must go through LEWG first. LEWG could simply adopt as a policy, that any library-only proposal must already be published as a library, for a minimum period of time, and having acquired users and integration in other public projects. This doesn't mean it has to be accepted into Boost first, although that is an option.

The "green light from LEWG" could be changed to a red light. My personal opinion is that if the only thing that LEWG did was to reject all pure library proposals for ten years, C++ would be improved.

Thanks

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Zach Laine wrote:

4) The one time I managed to cajole someone [from WG21] into [submitting a library for] a Boost review, it was rejected because people didn't see the point of it. I'm still not sure why that was. It had a point, is quite useful, and is now in the standard.

(My edits in [] for clarity, I hope.) You're referring to JeanHeyd Meneide's out_ptr, right? My recollection of that episode was that we just didn't have enough reviews. I think I saw that only about 3 had been written, so I thought I'd better try to write something. JeanHeyd wrote a long reply to my review which finished by saying something like "Lots of Fortune 500 companies are using this so it's definitely useful". The problem was, * those Fortune 500 companies didn't turn up on the list and submit positive reviews *. So you had to reject it, because a few ignoramuses like me didn't see the point. As you said, it's a lot of work to prepare a library for review - and then it only gets looked at by five people. In JeanHeyd's case, they were five people who mostly said no; I worry equally about reviews where libraries with significant defects get accepted, because the reviewers don't have the expertise to call out the problems. I'd love to see more reviews submitted by people in the "upper echelons" of the C++ world, even if they are brief ones. What are the obstacles that stop people from submitting reviews? Regards, Phil. (P.S. Zach, I tried to reply to you off-list to check if I was right about this being out_ptr, but it bounced from gmail's spam filter. Do you have unusually strong filter settings?)

niedz., 15 wrz 2024 o 20:35 Glen Fernandes via Boost napisał(a):

Zach Laine wrote:

...

The one time I managed to cajole someone [from WG21] into [submitting a library for] a Boost review, it was rejected because people didn't see the point of it. I'm still not sure why that was.

I'll note that I wrote a review where I could not justify accepting it, and all of my points had nothing to do with "didn't see the point of it" https://lists.boost.org/Archives/boost/2019/06/246514.php

I, on the other hand, felt that there was insufficient motivation offered to justify the addition of the library. I face this problem with many reviews. A proposal says, "Here's what I wrote, do you accept it?" and there is no motivation saying what problem it is solving, if the problem is worth solving, are there alternative ways of solving the problem. In other words, I expect of an author, not only the implementation and tests and documentation, but also having done research. This is a lot to expect. I can imagine why people do not want to go through all this. Regards, &rzej;

Zach Laine wrote:

Right. All those responses are valid. My point was not that the review outcome was problematic. My point was that the Boost review process and the WG21 review process have fundamentally different aims. Boost wants the best C++ libraries that appeal to its reviewers. WG21 wants to make sure something is appropriate for the standard. Those are similar, and even overlapping, but fundamentally different goals.

It doesn't really matter. For a library to get into the standard it needs to undergo design review by LEWG and be accepted by LEWG. Adding a Boost review on top of that can never be a "win" for the author, because it can only increase the probability of rejection.

niedz., 15 wrz 2024 o 21:43 Joaquín M López Muñoz via Boost < boost@lists.boost.org> napisał(a):

Enviado do meu iPhone

...

No dia 15 de set. de 2024, às 21:28, Peter Dimov via Boost < boost@lists.boost.org> escreveu:

Zach Laine wrote:

...

[…] Boost wants the best C++ libraries that appeal to its reviewers. WG21 wants to make sure something is appropriate for the standard. Those are similar, and even overlapping, but fundamentally different goals.

It doesn't really matter. For a library to get into the standard it needs to undergo design review by LEWG and be accepted by LEWG. Adding a Boost review on top of that can never be a "win" for the author, because it can only increase the probability of rejection.

It would if field experience weighed more in WG21’s acceptance criteria.

But because it often doesn't, the Beman Project does indeed fulfil an important role. If nothing else (and there is likely more, that I fail to appreciate), it allows one to prove that what is proposed is actually implementable. Recently, there was a situation in a WG21 triannual meeting that the proposal for inplace_vector had to be withdrawn in the plenary voting at the last moment because it was observed that what had been approved by the subgroups was unimplementable. Having the library in the Beman Project would have prevented that from happening. I am not saying that this is all good. But it could be worse without the Beman project. Anyway, I now understand that the expectation I expressed earlier, that the library authors after the hearing in LEWG should be directed to Boost is misguided. Thank you. &rzej;

Andrzej Krzemienski wrote:

niedz., 15 wrz 2024 o 21:43 Joaquín M López Muñoz via Boost < boost@lists.boost.org> napisał(a):

...

It would if field experience weighed more in WG21’s acceptance criteria.

But because it often doesn't, the Beman Project does indeed fulfil an important role. If nothing else (and there is likely more, that I fail to appreciate), it allows one to prove that what is proposed is actually implementable.

The Beman Project can be (and will be) tailored to the needs of LEWG. LEWG doesn't need a second opinion on the library design or utility; what they need is a place that would hold the reference implementations and their test suites and that would ensure that these meet some minimum (objective) quality standards (e.g. the test suite has sufficient coverage and compiles and passes.)

On Sun, Sep 15, 2024 at 12:21 PM Zach Laine via Boost wrote:

...the Boost review process and the WG21 review process have fundamentally different aims. Boost wants the best C++ libraries that appeal to its reviewers. WG21 wants to make sure something is appropriate for the standard. Those are similar, and even overlapping, but fundamentally different goals.

This might be how it is today, but it is not how it should be. The ongoing cost of an accepted Boost library is considerably less than the ongoing cost of accepting a new standard library component. When a library is accepted into the standard, it makes subsequent additions more expensive, as the new addition must be considered in the context of an expanded set of existing facilities. There was a brief discussion earlier this year about which libraries should be accepted into Boost. Peter's answer was "a library that is useful" (among other things of course). Being useful should be a necessary but insufficient quality of standard library proposals. Not only must they be useful, but they should appeal to a broad audience, and the paper must include the rationale for why the library should be incorporated into standard instead of remaining as a downloadable dependency from elsewhere. To my knowledge, no paper has ever provided a quantitative analysis for why it needs to be in the standard instead of existing as a third party library. I think they should. Thanks

On Tue, Sep 10, 2024 at 2:49 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:

Let me ask again, mostly the people that promote the Beman project, why do you think Boost is unfit for the purpose of incubating libraries that target the Standard Library?

Well, let's start with the fact that, for a long time now, Boost is not part of the incubation process for most libraries going into the standard. As to why this is the case, I don't think anyone knows for sure. There's the advent of GitHub as a C++ library distribution method, the emergence of CMake as the industry standard build system, the aging (and loss of relevance) of existing Boost libraries, the decreased tolerance of uncivil online behavior, the loss of key people in leadership, an increased prevalence of high-quality libraries being developed outside of Boost, etc. I don't want to count chickens before they hatch, but one might question why is the Beman project seeing success in this space in such a short period? It could be because it's "new and shiny", maybe it's because it's designed with today's environment in mind, maybe because the people on that project are so great to work with (that certainly keeps me engaged), or maybe it's because authors like getting the feedback but without the high-stakes Boost formal review process (they get something like that from the committee anyway). Who knows? We've got plenty of haters already predicting the demise of the Beman project. Why didn't the people working with Beman try to make changes to Boost that would make it more relevant for committee work? Well, several people did over a period of many years. Consider the Steering Committee CMake decision and the testing of a discourse server. There just isn't enough interest in the Boost community for making these changes, which is totally fine! Boost still serves an important purpose, but I don't know practically how to make it an incubator for most standard libraries while respecting its consensus process. It's sad there's so much negative energy in the Boost project towards the people volunteering their free time to support it in the Boost Foundation, even recognizing much of it is based on misunderstandings. No one should be surprised why most of the board has steered clear from these discussions. -- David

On Tue, Sep 10, 2024 at 6:03 PM Matt Borland wrote:

...

It's sad there's so much negative energy in the Boost project towards the people volunteering their free time to support it in the Boost Foundation, even recognizing much of it is based on misunderstandings. No one should be surprised why most of the board has steered clear from these discussions.

But, if I am reading this correctly, then this means that the Boost Foundation is actively avoiding engagement with the Boost community.

I don't think this accurately characterizes what I said. I'm talking about individuals undergoing an incredibly stressful time with competing emotions such as guilt for not doing more to prevent what Boost is becoming (or has become) and dread of walking into a shitstorm. If the board of a foundation can't engage with the community they literally

share a name with, perhaps it's time to move on?

The Boost Foundation was the one that asked the community to decide on governance. If the decision goes in the direction it looks to be going, I'd be highly surprised if the foundation will want anything to do with the new Boost. I can't fault the foundation for divesting Boost assets, and reorganizing

into say the Beman Project Foundation as that is now clearly the focus area, and place where you see the ability to affect change.

Beman is just one of several interesting Boost Foundation projects. I happen to be a member of the Beman project and the Boost Foundation. Others in the Foundation are mostly involved in other projects, like the C++Now conference.

I would not waste my time volunteering on something I felt was against me either.

I'm personally motivated out of concern that the Boost brand will be tarnished by new Boost. This is something that will impact many of my friends who have contributed so much to Boost's success and have an identity with it. However, I think this decision will make a clear separation point between old Boost and whatever becomes of new Boost.

On Tue, Sep 10, 2024 at 6:42 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

WG21 is incapable of competing in the library marketplace.

This outlook will repel folks working on WG21 from coming here.

On Tue, Sep 10, 2024 at 7:46 PM Klemens Morgenstern < klemensdavidmorgenstern@gmail.com> wrote:

On Wed, Sep 11, 2024, 7:33 AM David Sankel via Boost < boost@lists.boost.org> wrote:

...

On Tue, Sep 10, 2024 at 6:42 PM Vinnie Falco via Boost < boost@lists.boost.org> wrote:

...

WG21 is incapable of competing in the library marketplace.

This outlook will repel folks working on WG21 from coming here.

Why? Do you think they can't take criticism?

Yep, you got it. They're just not man enough to come to Boost and take one on the chin!

On 9/10/24 3:42 PM, Vinnie Falco via Boost wrote:

On Tue, Sep 10, 2024 at 2:34 PM David Sankel via Boost wrote:

...

...Boost is not part of the incubation process for most libraries going into the standard. As to why this is the case, I don't think anyone knows for sure.

I have a theory....

I believe that making standardization the primary goal is a mistake. The goal must always be to satisfy users by delivering something useful. The standardization follows, and does not lead. This is why Boost is now more important than ever: WG21 is incapable of competing in the library marketplace.

Vinnie. I don't think I'm considered a member of your fan club, but regardless, this is an EXCELLENT post and cogently summarizes the history and current situation regarding the relationship between WG21 and Boost. Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

No dia 11 de set. de 2024, às 14:28, Andrzej Krzemienski via Boost escreveu:

I am considering proposing my small library into Boost, and I also feel a bit uncomfortable. First, it is my understanding that I need to come "prepared". That is, have done the research, have a repo, docs, tests, answers to many questions. That is ok, I guess. The thing I fear most is that I would have to integrate my library with the Boost infrastructure. It may be just perception, but the subprojects, b2 stuff is above my level. I know that I would receive help. But still, the amount of the perceived complexity puts me off.

You’re welcome on the Slack Boost group, where we can help you put your lib in good shape for proposal! FWIW, I’ve contributed several libs to Boost and b2 is still above my level :-) I don’t know what that says about b2 complexity and/or my professional competence, but it shows that the tool is not an insurmountable obstacle. I always depended on the kindness of experts, and so can anyone. Much such activity goes on on Slack that’s not reflected on the ML. Joaquin M Lopez Munoz