What is this "Beman Project Development" exactly
I confess that I'm totally mystified by this. I've looked over the web page and it doesn't help me. 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." "Equally important to our mission is the guidance provided by our shared values. These are transparency, inclusivity, consensus-building, federated authorship, and community-driven leadership." 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 (excluding the woke paragraph it the Boost Foundation version. A couple miscellaneous questions: a) Why is the Boost Foundation website not part of the Boost.org website? b) So what's the point of all this? Who has promoted/championed it? What is their motivation. Extremely odd to me. add your own questions here. Personally I'd like to see the following: a) consolidation of all this under one umbrella b) More transparency in selection of board of directors. More direct influence on the part of library creators and users. I don't have any idea how to achieve this without creating caos though. c) Distancing Boost from the C++ standard. Boosts original mission was accomplished when the standards committee incorporated a large part of boost directly into the standard. Since then boost's policy of working with the standard library is very confusing. Are we an alternative? or are trying to create new (better?) standard library components. Or are we trying to create canonical implementations of the standard library components? The standard committee is flailing around itself. Three way branch? executors? Does something as elaborate as ranges belong in a standard library? What about testing the standard library? How do we do this? or Not. Do I incorporate the standard library in my heart pacemaker app? Without being able to test any of it? Oh let's not forget "modules" I've been reading up on it and it seems at most a half-baked idea. So boost should only focus on the standard to the extent that it needs to in order to make it's own libraries work. Sorry, I'm just not understanding any of this. Robert Ramey
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).
On 5/8/24 6:23 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.
I looked over the Beman website and discourse and found no useful information other than the mission statement which I quoted.
It would probably be best to solicit them there than to speculate here.
I'm not speculating. I'm asking so I don't have to speculate.
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).
As I understand it, issues separate from library development per se were what the Boost Foundation was designed for. And it seems to have worked well for that. Members of the board have always been welcome to work on the library development side on their own and many have. So my question remains unanswered: "What purpose can the project serve which is not already addressed by Boost?" Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, May 8, 2024 at 8:24 PM Glen Fernandes via Boost <boost@lists.boost.org> 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
Robert Ramey via Boost <boost@lists.boost.org> 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). 3. Not worry about Boost reputation of being bloated, monolithic, and heavily intra-dependent.
On 5/9/24 13:52, Boris Kolpackov via Boost wrote:
Robert Ramey via Boost <boost@lists.boost.org> 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.
Andrey Semashev via Boost <boost@lists.boost.org> writes:
On 5/9/24 13:52, Boris Kolpackov via Boost wrote:
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.
I think it's true to a certain extent. Even in case of the Boost Project you would have been able to drop a lot of baggage if you were starting something like Boost2. In case of the Beman Project, they can practically do such house cleaning every time a new version of the C++ standard is released and compiler support is reasonably available. And they can take this opportunity to drop other baggage, like switching to the build system or package manager that is currently in vogue, dropping libraries whose authors have lost interest, etc.
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
Vinnie Falco wrote:
On Thu, May 9, 2024 at 6:1 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.
In theory, if all you want is a repository of reference implementations, you can drop a library once it's accepted into the standard, or when it's rejected and the author no longer wants to pursue standardization. In practice, of course, once libraries acquire users, it's not so easy to just drop them.
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.
All good comments and ideas. It seems that we all have to guess what the purpose will be and what methods the "Beman Project" will use. At this point we'll just have to wait until they post more content. As an aside, I also think the usage of a revered, deceased founder of Boost is tacky. Robert Ramey
On 5/8/24 4:19 PM, Robert Ramey via Boost wrote:
I confess that I'm totally mystified by this. I've looked over the web page and it doesn't help me.
Motivated by some of the comments and observations, I spent a little more time delving into the information available on the beman project. The most intriguing/revealing page I found here: https://github.com/beman-project/beman/blob/main/docs/governance.md Seems pretty clear that the goal is to provide library implementation for the C++ standard library. Very similar to the founding of Boost. But the structure is quite a bit different. Beman Project Leads. It (currently)has three "project leads". "The Beman Project Leads are responsible for maintaining the Library Acceptance and Incubating process. This includes strategic planning, setting goals, and ensuring the organization's objectives are met." Although the goal of contributing to the standard seems similar to the original goal of Boost, the means proposed to accomplishing it seem 180 degrees different. There is no defined review process, reviewers, review manager, review wizard as these functions are the responsibility of "project leads". The group of project leads is increased/decreased by solely by consensus among the project leads. Currently, the designated project leads are: Jeff Garland, David Sankel and Inbal Levi. Beman Project Contributors. The Beman Project Contributors are individuals who help execute the facilities provided by the Beman Project. That's all it says. I have no idea what this might mean. Beman Project Library Authors. The Beman Project Library Authors are the Library authors who are maintaining and improving the libraries that are part of the Beman Project. I think I know what this means. So there it is. Original Boost Goal of creating implementation of ideas proposed for standardization, but only such libraries. Managed top-down rather than bottom-up as boost.org is. It's stated that this is not intended to replace boost.org. I believe this as since C++11, role of boost.org in this role is much diminished if not eliminated. For this same reason I believe that this idea will be a flop. That's even without considering the issues raised by modules. Again, Boost should distance itself from the standardization process which has arrived at a cul-de-sac where imagination, inspiration and sometimes genius is replaced by negotiation, consensus building, politics and petty parochial interests. They can do their thing, we'll do ours - which is develop innovative imaginative C++ software. One thing I do like about this project is that has tried to address our issues related to tools and looks like they've provided an interesting alternative starting point. Our tools have become too complex to use and maintain. To be fair, a lot of this problem is due to the complexity of C++ itself. I know we've been working to try to fix this, but let's face it, it's not working. Robert Ramey
participants (7)
-
Andrey Semashev -
Boris Kolpackov -
Glen Fernandes -
Peter Dimov -
René Ferdinand Rivera Morell -
Robert Ramey -
Vinnie Falco