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

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 24, 2025, 12:53 UTC
Message-ID: <aNPp5jA5k_nDNmyd@pks.im>
In-Reply-To: <xmqqqzvxp7ej.fsf@gitster.g>

On Tue, Sep 23, 2025 at 07:31:32AM -0700, Junio C Hamano wrote:

Show 16 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> > There's a couple reasons:
> >
> >   - The LTS maintainer may not be as familiar with the Git codebase as
> >   - The LTS maintainer may not be as trusted as other regulars on the
> 
> If you assume that you can only get incompetent folks who would not
> be trusted by their users by their own ability and dedication, I do
> not think an endorsement by the main project would help them gain
> trust at all.  All it would do to force the main project to blindly
> sign their output is to tarnish the brand of the main project.
> 
> In other words, you are assuming that no competent folks would want
> to be the "LTS maintainer"(s), and you are arguing that if we really
> want a "Rustless Git", which will be used by the general public, to
> exist, we should be the ones that are working on it.

I think there's a wide range between "competent" and "incompetent". I would generally assume for example distro maintainers to be competent, but they probably don't have as much expertise in the Git codebase compared to a frequent committer to Git. So there's nuances here, and I think in such cases everyone would benefit if they had a helping hand from the Git project.

Show 22 quoted lines

> >> edge.  Most importantly, a coordinated disclosure would say that the
> >> update to versions of
> >> 
> >>  - Git 3.0 to Git 3.4 are found $HERE, 
> >>  - Git for Windows 3.0, 3.2, and 3.4 are found $THERE
> >>  - Git 2.98 are found $COMMUNITY_LTS
> >> 
> >> to make sure that people know where to find their updates.
> >> 
> >> So, no, I do not think we should unnecessarily mix community LTS and
> >> the main project.
> >
> > How about the following tradeoff: the community LTS is developed outside
> > of the usual Git workflow, for example on a forge, so that the LTS
> > maintainers can work in their preferred flow. But eventually, once they
> > want to do a release they send a pull request to the Git mailing list
> > and then the tag lives in the canonical Git repository.
> 
> I do not think, with your assumption that LTS maintainer(s) are
> incompetent ones that cannot gain users' trust by themselves, such
> an arrangement would work.  Its only effect would be to tarnish the
> brand of the main project if we rubber stamp endorse their ware.

Yeah, rubber-stamping doesn't really help indeed. The idea wasn't to do that though, but to still do a sanity check of the new version.

I guess ultimately we'll have to figure out the details along the way. There's many questions we cannot answer at this point in time yet, like:

  - When is the LTS maintainership handed over to the community?

  - Who is the community member that takes over maintainership of the
    LTS release?

  - How long do we expect to require the LTS release?

  - Will we even need it in the first place for Rustless builds?

So maybe it's premature at the current point in time to already spell out details. Should we maybe just defer that decision into the future? E.g. something like the below patch.

Patrick

diff --git a/Documentation/BreakingChanges.adoc b/Documentation/BreakingChanges.adoc
index 3b54750621..bf3173013d 100644
--- a/Documentation/BreakingChanges.adoc
+++ b/Documentation/BreakingChanges.adoc
@@ -200,9 +200,9 @@ 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 long-term release tags will be created in the canonical Git repository.
+in case they need to extend the life of that long-term release even further.
+Details of how this long-term release will be handed over to the community will
+be decided once the Git project decides to stop officially supporting it.
 +
 We will evaluate the impact on downstream distributions before making Rust
 mandatory in Git 3.0. If we see that the impact on downstream distributions