Replies: 15 comments 73 replies
-
|
@djowel, sorry for the long message. If you don’t have time to review all the details, I’d just appreciate maintainer access to the relevant repositories. That way, I can start making practical, well-considered decisions on my own. (I'm always open to feedback, of course.) |
Beta Was this translation helpful? Give feedback.
-
|
The main reason I've stopped working on improvements is because I got yelled pretty much every time I fix a bug or change some internal stuff that no one should've relied on. And I get their viewpoint, Boost nowadays is seen as a collection of mostly legacy battle-tested libraries, a project uses Boost because it have used it for a long while and people that maintain it don't want their working code been disturbed. Have you done a research on consequences of deprecating and removing Spirit.Classic? I also was naïve, though it could be done, until I discovered that not only there are huge open source projects that still use classic version, https://github.com/boostorg/wave is using it. |
Beta Was this translation helpful? Give feedback.
-
|
In short: I will make breaking changes if I believe that's the practical solution. Well, I'm okay with getting yelled at, if it is the consequence of breaking changes. Someone needs to break things if the root cause is the unmaintained code. When I was an ordinary user, I myself was sometimes one of those people who are yelling at maintainers. But if I am going to be the maintainer, I guess I need to live with that. Maintainers have the right to deprecate things. People have the right to yell at maintainers. These two facts can exist simultaneously. In other words: I promise to always be open for any sort of feedback (from both maintainers and community users), but, at the same time, I don't care if people are yelling at me for my realistic and practical decisions that I make as a maintainer. In case if I get mentally destroyed then I'll just step down. But that's not something that would be happening anytime soon. I am just getting started. Honestly, I'd personally like to thank you for all your works done in recent years. |
Beta Was this translation helpful? Give feedback.
-
|
That's not how things are supposed to work. If you don't want to maintain Spirit Classic, then don't. Deprecating and removing it is not the same thing. Ideally, it would be split into its own repo, and left to whoever wants to maintain it. (And if nobody wants to do that, then I win that honor by default, because someone has to. Not that I'm thrilled to maintain everything, or even have time to, but there's no realistic alternative.) And that goes for every Spirit project; all these things need to be separate repositories, with their own willing maintainers, or lack thereof. |
Beta Was this translation helpful? Give feedback.
-
Boost.Serialization uses it, for one. And is unlikely to be fixed if broken by its removal. (Even if we ignore Quickbook.) |
Beta Was this translation helpful? Give feedback.
-
|
People always have the right to stick to a specific Git commit hash. People always have the right to keep their own tarballs. Nobody is obliged to keep their now-obsolete code forever. Remember, Boost had actually done it for dozens of years and it is now causing real issues! Seriously, take a look at @Kojoley's comment. Boost itself has proven that such ignorant stance is against the sustainability of an open source project. It's causing real harm to the maintainers. |
Beta Was this translation helpful? Give feedback.
-
|
Well, I honestly didn’t expect the very first "yell" to come from a core developer. Much appreciated. I guess that's how veterans treat newcomers on this community. Very good. I'm still looking forward to hearing from @djowel soon. |
Beta Was this translation helpful? Give feedback.
-
No, that's not possible in Boost. Quickbook can't stick to a specific Git commit hash of Spirit. And even if it could, if library X picked a certain Git commit hash and library Y picked a different Git commit hash, library Z wouldn't be able to use X and Y. |
Beta Was this translation helpful? Give feedback.
-
That wasn't a "yell", I proposed a way forward that would give you what you want (no Classic in this repo) while avoiding the yells. And in return, you accused me of treating newcomers harshly. Fair enough, I suppose. Either way, this conversation properly belongs on the list because the effects of the discussed changes have a much wider impact. |
Beta Was this translation helpful? Give feedback.
-
|
I agree that this discussion about deprecation should probably be done in the Boost list. The list is so alien to me now, but I'll chime in if there's some discussion. I do see the reason behind @pdimov 's concerns, though. And actually, maintaining classic isn't that much of a burden, compared to Qi/Karma/X3 —as long it is frozen, with no new changes. That said, I’m not sure if there’s any difference between removing a library and deprecating one, in terms of their impact on dependent libraries. Also, I don’t believe a lifetime commitment is required for a Boost library. Meanwhile, let's give you access to the repos. |
Beta Was this translation helpful? Give feedback.
-
|
Everyone interested on this matter should comment on this thread. I'm going to pin this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
@djowel @pdimov May I ask you to clarify whether there are any existing deployments of battle-tested parsers built on Classic? This information is important for a broader investigation aimed at understanding the real-world impact—not just hypothetical concerns. I’m looking for examples of production-level applications used by real companies, not abandoned frameworks with thousands of commits that have sat unmaintained on GitHub for years, as those likely aren’t being used to solve real-world problems. |
Beta Was this translation helpful? Give feedback.
-
|
FYI: As the new maintainer, I’ve addressed all open PRs, except for the hard ones that require input from other maintainers |
Beta Was this translation helpful? Give feedback.
-
|
For reference, there are 2 issues that might affect the transition of Classic. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the noise, but just a heads-up about upcoming changes: I'll be adding labels to all existing PRs, including the closed/merged ones, from now on. I've already done this for regular issues, and I've decided it's necessary for PRs as well. Labels are important for making search work well. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I’ve been endorsed as the new maintainer of Spirit by @djowel!
See this thread for context: #800 (comment)
@djowel, I’d really appreciate your feedback on the items listed below. Would it be reasonable to assume that I, as a maintainer, can move forward with the actions described here?
cc: @Kojoley
Gaining Access to the GitHub Organization
What’s the process for obtaining maintainer access to the relevant repositories?
If I understand @djowel’s intent correctly, I should be granted access to Spirit along with the accompanying libraries.
Deprecation and removal of Spirit.Classic
Documenting "Classic is now deprecated." is easy. However, in practice, that won’t meaningfully change how the codebase is used. As long as the
classicheaders remains in the repo, users will continue to rely on it, just as they have for the past 15 years.So my plan is to first document the deprecation clearly in the official docs. Then, after a few major Boost releases, we should proceed to remove the Classic codebase entirely.
Deprecation of Spirit.Qi
I understand Qi is still used in many production systems and mature codebases. That said, I believe we should also begin deprecating Qi—though more gradually than Classic.
My reasoning:
(future) Deprecation of Spirit.Karma
To my understanding, Karma can't be deprecated or removed soon, as there's no alternative implementation. Someone needs to write a brand new serialization system based on the X3 codebase, but this is gonna be an independent matter, I guess. For now, I don't have any immediate plans for this.
Or... should we just remove it and state that "serialization is not supported"?
Deprecation of the accompanying libraries (Fusion, Phoenix, Tuple)
As far as I know, they are mainly used by pre-X3 codebase for metaprogramming. C++23 makes most of this possible natively. Given that, I believe we should also deprecate these libraries.
Migrating documentations
I'm planning to migrate X3's docs to AsciiDoc. It's going to be a substantial PR, and I’d like to avoid the risk of it being rejected due to stylistic preferences or legacy concerns. How should we build consensus for major changes like this? Should I just simply submit the PR?
Beta Was this translation helpful? Give feedback.
All reactions