On Wed, May 8, 2024 at 8:24 PM Glen Fernandes via Boost wrote:

On Wednesday, May 8, 2024, Robert Ramey wrote:

...

I confess that I'm totally mystified by this.

Answers to questions about the Beman project would be more readily found on that project's Discourse. It would probably be best to solicit them there than to speculate here.

I'm interested in continuing the thread that explores a direction for Boost on this mailing list independent of what other projects want to achieve.

This includes people in the community willing to step forward to steer Boost in said direction.

Note that that the same community has already more or less expressed the desire for the Foundation to not interfere with the C++ library development side of things (and serve only in a supportive role with infrastructure and so on).

Boost authors have learned to do with what they have as the steering committee and then foundation provided essentially zero support. A personal example of that is the current release build and packaging process which I created. It was easier and faster to write code to make use of freely available CI resources than to ask the foundation, or anyone, for support. So, yes, it's a really good question what the foundation's role can be in the bottom up federated organization that is Boost? Also interesting questions.. 1. Is the current "making directional decisions in the event of Boost community deadlock" aspect working? I.e. Has it ever had an actual effect? 2. Equally, has "fostering community engagement" been effective? 3. And subsequently, also "nurturing leaders"? 4. And finally there's "providing necessary financial/legal support"? Do we need a foundation to do those? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

On 5/9/24 13:52, Boris Kolpackov via Boost wrote:

Robert Ramey via Boost writes:

...

Here is the "mission statement" from the Boost Foundation website:

"The Boost Foundation’s broad C++ mission is: (a) development of high quality, expert reviewed, legally unencumbered, open-source libraries, (b) inspiring standard enhancements, and (c) advancing and disseminating software development best practices. It does this by fostering community engagement, nurturing leaders, providing necessary financial/legal support, and making directional decisions in the event of Boost community deadlock."

[...]

Here is the "mission statement" from the Beman Project:

"The Beman Project’s mission is to support the efficient design and adoption of the highest quality C++ Standard libraries through implementation experience, user feedback, and technical expertise. Founded at C++Now in 2024 the project strives to aggregate libraries proposed for ISO standardization making a simple usage experience for the C++ Community to try out new libraries. For library authors we assist by helping to make best modern development practices easy. Including CI, coverage, and packaging."

Seems to me that they are essentially the same with different wording [...]

Seems very different to me: the Beman Project appears to be focused on libraries aiming at being included into the C++ Standard Library. This means they don't have to worry about any of the Boost baggage:

1. They can track the latest standard (since by definition such libraries will only be usable with later standards). Maybe they can even go straight to modules.

2. Not worry about build systems and package managers (they can live in the blissful world of C++ that has a standard package manager, it just has one giant package that gets a new version every three years).

I don't think #2 is true, and I doubt #1 is entirely true either. A library proposed for inclusion into the standard has to work and solve the intended problem efficiently. This means testing and field experience are prerequisite, and for that the library has to be usable with current compilers, even if modern. And yes, that includes a build system and packaging, if required by the library. That is unless the LWG is willing to accept unverified and half-baked libraries into the standard library, which I strongly hope is not the case.

On Thu, May 9, 2024 at 6:10 AM Boris Kolpackov via Boost < boost@lists.boost.org> wrote:

... Boost baggage...you would have been able to drop a lot of baggage if you

were starting something like Boost2.

What you call "boost baggage" is what other companies and individuals call a robust mature codebase upon which they have built software with economic value. Perhaps these battle-tested components can be dropped but the users who rely upon them would also be "dropped." A "house cleaning" every 3 years has two problems: 1. It falsely implies that the "house" is "dirty". 2. The C++ world doesn't much embrace completely breaking working code at regular intervals. Thanks

Boris Kolpackov wrote:

Seems very different to me: the Beman Project appears to be focused on libraries aiming at being included into the C++ Standard Library. This means they don't have to worry about any of the Boost baggage:

1. They can track the latest standard (since by definition such libraries will only be usable with later standards). Maybe they can even go straight to modules.

If they want to be merely a repository for reference implementations of standard proposals, yes. But the second a library acquires actual users, it also starts acquiring compiler workarounds.

2. Not worry about build systems and package managers (they can live in the blissful world of C++ that has a standard package manager, it just has one giant package that gets a new version every three years).

They do have to worry about build systems if they want their libraries to actually build. They'll be using CMake for that from what I can tell. The situation with the package managers is similar - if their libraries become actually usable, package managers will start packaging them.

3. Not worry about Boost reputation of being bloated, monolithic, and heavily intra-dependent.

Every step of Boost's evolution happened for a reason, and these reasons don't magically disappear when you fork it. Again, the second a library becomes actually useful, other libraries would want to start using it. You could extend this list with (4), (5), and (6), and the responses to each of these points will be very similar to the above.