Sorry for the delay; life outside of work is challenging at the moment... On Thu, Sep 4, 2025 at 11:50 PM Patrick Steinhardt <ps@xxxxxx> wrote: > > On Thu, Sep 04, 2025 at 08:54:19PM -0700, Elijah Newren wrote: > > On Thu, Sep 4, 2025 at 4:40 AM Patrick Steinhardt <ps@xxxxxx> wrote: > > > > > > On Thu, Sep 04, 2025 at 12:57:25AM +0000, brian m. carlson wrote: > > > > On 2025-09-03 at 05:40:54, Patrick Steinhardt wrote: > > > > Also, the approach of making it an optional component directly > > > > contradicts the proposed policy I wrote up. That's a recipe for > > > > additional burdensome work maintaining two implementations, when we > > > > actually want to make it easier for people to contribute functionality. > > > > It also doesn't provide any of the memory safety benefits or address any > > > > of the concerns from governments, security professionals, and other > > > > parties about the real and substantial risks of continuing to develop in > > > > C. > > > > > > The only reason why we want to have it as an optional component is to > > > make the transitioning period easier for downstream distributors. And > > > the intent is not to convert major components -- it should be trivial > > > components that we can use as test balloons, similar to how we did it > > > for all of our C99 test balloons. > > > > > > We cannot just pull the rug away under their feet without advance notice > > > that this is going to happen. > > > > I find this statement a bit problematic for four reasons: > > > > (1) "without advance notice" was already pointed out to be inaccurate > > in this thread, including in the exact email you are responding to; > > you could argue that there hasn't been _sufficient_ advance notice, > > but then there should be more details about what is and isn't > > sufficient. Merely repeating this claim which brian just barely > > pointed out to you as false almost feels dishonest. > > I think there is a difference between communication that happens on the > mailing list/contributors summit and communication that is intended for > the broader ecosystem: > > - The former is basically us developers discussing potential futures > and reviewing patches. It would be _nice_ if distro maintainers of > Git were to read these, but given the large volume of traffic in > general I think it unlikely that majority of maintainers is keeping > up with that traffic. > > - The latter is in the form of e.g. our release notes as well as our > BreakingChanges document. These _are_ intended to be reviewed by > maintainers, and the blame is on them if they don't do so. > > We have never communicated either via release notes or via any kind of > committed document that Rust is going to become mandatory. There have > been lots of large threads discussing it, true. But navigating these > threads and estimating consensus isn't easy even for us developers, so > it's going to be even harder for outsiders to the community. I like this framing; this is useful. I agree that we haven't communicated that it'll be mandatory, though we have communicated beyond the list that Rust was likely coming: * The contributor summit notes on Rust (posted at https://lore.kernel.org/git/Zu2D%2Fb1ZJbTlC1ml@nand.local/) were widely picked up at other sites (e.g. https://lwn.net/Articles/998115/, https://www.reddit.com/r/linux/comments/1hcsvk5/nonstop_discussion_around_adding_rust_to_git/) * The release notes mention initial Rust inclusion (https://lore.kernel.org/git/xmqqfrjfilc8.fsf@gitster.g/, "Foreign language interface for Rust into our code base has been added.") * The GitHub blog on highlights from 2.49.0 (widely linked at news sites even in preference to the release notes) adds more detail: "This release marks a major milestone in the Git project with the first pieces of Rust code being checked in" (https://github.blog/open-source/git/highlights-from-git-2-49/) Now, I can fully get behind that this may be _inadequate_ notice, and I really like the idea of a test balloon. I'm just noting that I very much disagree with the characterization that there has been no notice beyond the mailing list about Rust likely coming at some point, and want us to make sure that if we delay, we use the time to meaningfully provide more notice than we have already. Another optional Rust component that doesn't build by default, for example, fails that test. > > (2) "pull the rug away" seems hyperbolic. I would have liked some > > explanation as to how a transition period is expected to help, and how > > the existing transition period has been insufficient. You do hint a > > little at the former, which I'll discuss more in point 4, but you > > neglect the latter to the point of pretending it didn't exist. In > > short, why is a further transition period needed, and how will it > > differ from the existing one we've already had? It's not clear to me > > why distributors must immediately update to the latest git version. > > Taylor discussed this aspect in detail in this thread; you even > > responded briefly (and tangentially?), but still as far as I can tell > > presume the latest and greatest is mandatory for them to adopt without > > stating why. Maybe they do need to adopt the latest and greatest, but > > I haven't seen folks state why that's the case. Did I miss it? > > The problem here is that we don't have a story to tell yet. I agree that > not everyone always needs the latest and greatest, which is also why I > mentioned that I think it's fine for _new_ features to be developed in > Rust right away. > > But the story is altogether different for bug and security fixes. > > - We of course backport security fixes, but would that also be the > case if we had ported the subsystem to Rust already and now had to > implement the security fix twice? > > - What happens if only the old C version has a security bug? Do we > still fix it? > > - Likewise, what happens with important bug fixes? We tend to backport > those that are easy-ish to backport, but if people are potentially > stuck with an older Git version for years it will become harder for > us to do so. > > I think without us having a proper answer to these questions we _are_ > pulling the rug away. Distros may be stuck with an old version of Git > for a significant time, and from my point of view we have to do a couple > of compromises there. These are good questions...but they are ones to which I suspect delaying will not provide the answer. In fact, I don't think we'll _ever_ have the answer to these questions, no matter how much we delay or discuss. Traditionally, if an issue was more severe, it has been backported to more versions, even if the backport wasn't trivial. There's a cost/benefit tradeoff to be had for each vulnerability, and changes to the area making backports either be easy or hard always need to be weighed against the severity of the vulnerability. I don't see that changing, and overpromising hurts in the long run probably more than having no guidance. I just don't see us coming up with "proper answers" (which I'm guessing means fully spelled out answers?) to these questions ahead of time. The answer to all of them is probably "we'll weigh the severity of the issue and the cost to backport and give the last C-only version significant extra weight in our considerations". I doubt we'll ever be able to promise any more detail than that until we get concrete cases; I'm not even sure that this statement is acceptable to everyone on the list from the overpromising angle despite being as incomplete as it is. > > It also feels like Rust support is being lumped in with "breaking > > changes", which to me feels misleading. Historically, we have talked > > about breaking changes and deprecation periods and such so that users > > could adjust scripts or their command lines such that they would work > > across multiple versions of Git. The Rust case is somewhat different > > in that we're not discussing behavioral changes of git, merely > > implementation differences. If someone has both a C-only version of > > git and a newer version of git that was built with both Rust and C, > > any commands they run should behave the same as far as the C-vs-Rust > > goes (unless we have our normal discussions about specific behavior > > and any deprecations we want to do related to it, of course). > > > > I do agree that reduced platform support is a negative change (though > > Rust brings other advantages that may offset this downside depending > > on your viewpoint), but I don't see why it's a breaking change and > > especially not a "pull the rug away under their feet" change. > > I honestly don't quite understand this perspective. How isn't it > breaking that you cannot use that Git version at all anymore? Users might often face cases where they have to use different versions of git -- at home, at work, on different work machines, etc. As such, when something forces workflow changes, we have to be cognizant of that and provide deprecation periods, release announcement notices, etc. That's the point of our care around breaking changes. If _distributors_ can't build a new version of git, users can still use older versions. They don't have to change their workflows. When distributors eventually figure out how to build a newer version (because they work around pthreads not existing on their platform, or they add stdbool to their compiler, or they port Rust to their system or whatever), then when the new version becomes available, users can use it without changes to their workflow. The _users_ weren't broken. I still don't see why distributors _must_ ship the latest version of Git and why folks on some platforms are considered broken if they are using a slightly older version. Let me ask again: has anyone answered why this is considered mandatory? If they have, I've missed it, but I've asked multiple times. Even if you want to lump "distributors cannot build a newer version" under the umbrella of "breaking changes", I argue it's a much different kind of break and one which merits different timelines for handling than e.g. lumping it in with 3.0. > > (3) the use of "cannot" presupposes the policy stance which we are > > having a discussion about, which, whether intended or not, feels like > > an unfair way to attempt to shut down the conversation. > > Sorry, that's not my intent. Thanks, and I appreciate you patiently explaining your point of view in more detail. > > (4) you suggest that adding Rust as an optional component should avoid > > the problem, yet we've already had Rust as an optional component for > > the last three releases, going back to 2.49.0. (libgit-rs and > > libgit-sys). > > I don't really think that either libgit-rs or libgit-sys help in any > way. These are part of "contrib/", not built by default, and neither are > they consumed by anyone out there. So there is no reason for anyone to > build that library to the best of my knowledge. I'm fully willing to accept they are inadequate notice (and perhaps even barely helpful), but disagree with the characterization that they don't help at all: * they were consumed in the past by Google * they recently received patches from someone outside Google (https://lore.kernel.org/git/20250826233525.2635432-1-davvid@xxxxxxxxx/) * they were mentioned in the release notes highlighting at a minimum that Rust is being added to Git. * they were highlighted in blog posts from both GitLab and GitHub as being noteworthy new things in the v2.49.0 release I agree with you there is certainly more we can do, and I like your idea of a test ballon. Let's just avoid repeating the problem of adding an optional component that no one will try to build except for those for whom we know can build it; doing that would provide no more notice and thus provide no incremental benefit over libgit-rs and libgit-sys.
