Subject: Re: [PATCH RFC v4 7/9] BreakingChanges: announce Rust becoming mandatory

From: Patrick Steinhardt <[email-masked]>
Date: Mon, 15 Sep 2025 12:53:12 +0200

On Wed, Sep 10, 2025 at 02:20:24PM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <[email-masked]> writes:
> 
> > +* Git will require Rust as a mandatory part of the build process. While Git
> > +  already started to adopt Rust in Git 2.52, all parts written in Rust are
> > +  optional for the time being. This includes:
> > ++
> > +  ** Subsystems that have an alternative implementation in Rust to test
> > +     interoperability between our C and Rust codebase.
> > +  ** Newly written features that are not mission critical for a fully functional
> > +     Git client.
> 
> This is a bit funny way to phrase the intent, even though I do fully
> support the intent expressed here.
> 
> When this topic becomes part of the code base, we are likely to have
> varint in the first category, but if we have nothing that falls in
> the second category, that would feel somewhat odd.

The intent here is to open the door for those. So yes, right now we
don't have anything in the second category yet. But the intent here is
to explicitly say that people are free to do it even if there is no such
user in our tree yet. And with the SHA256 interop code we already have
this feature in the working anyway :)

> > +These changes are meant as test balloons to allow distributors of Git to prepare
> > +for Rust becoming a mandatory part of the build process. There will be multiple
> 
> Are they still "test balloons"?  I thought that we established that
> the point of these breaking changes is quite different from what we
> have called "test balloons" for.  It is not like allowing them
> anything (like interfering to delay or stop, which would not likely
> to happen at this point if this patch gets part of the code base),
> but is used as a bit more forceful way for us to tell them and make
> sure they are aware of the upcoming change.

I'm mostly just lacking a better term here and haven't seen a different
term proposed anywhere. I think it's close enough to a test balloon to
call it that, but if anybody has a better way to name this thing I'm
happy to adapt.

> > +The Git project will declare the last version before Git 3.0 to be a long-term
> > +support release. This long-term release will receive important bug fixes for at
> > +least four release cycles and security fixes for six release cycles. The Git
> > +project will hand over maintainership of the long-term release to distributors
> > +in case they need to extend the life of that long-term release even further. In
> > +that case, the backporting process will be handled by these distributors, but
> > +the backported patches will be reviewed on the mailing list and pulled in by the
> > +Git maintainer.
> 
> I am having a hard time imagining the practicality of this "hand
> over but we still review" arrangement.  Some of the security fixes
> are embargoed, and the reason why we are jetissoning the stale
> codebase is presumably because nobody is willing to work on it other
> than the "community support" folks.  I can imagine that we would
> qualify them into the git-security cabal and let them use the forum
> to coordinate among themselves, but then to what degree in the
> "community support themselves" process is our involvement expected?
> As long as we can make sure that they do not leak before the
> official embargoed release, they do not need an official stamp of
> approval from the project or by the Git maintainer---that is what it
> means to "hand over maintainer ship", at least to me.
> 
> In other words, I like what I see in this paragraph, but I do not
> think we can practically live with the part of the sentence after
> the last ", but".

I think the most important part here is that this community-supported
LTS release should still live in the canonical repositories. We should
avoid the situation where we hand over maintainership to such a degree
that the end result (the tagged LTS release) lives somewhere else.
Otherwise we risk chaos and a plethora of different LTS releases, which
would be harmful both for us and those that rely on the LTS releases.

So this requires us/you to pull in those changes into the LTS release
branch. And that from my point of view mandates that we also review
whatever is being proposed for the backports. The mode thus essentially
becomes that somebody else does the legwork of selecting patches that
need to be backported and massaging them so that they apply to the old
Git version. But other than that we still follow the normal processes.

And yes, that probably means that a trusted LTS maintainer should be on
git-security@ so that they are aware of upcoming security releases.

Patrick