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

From: Patrick Steinhardt <ps@pks.im>
Date: Sep 23, 2025, 05:32 UTC
Message-ID: <aNIw23JzQE1vz2JD@pks.im>
In-Reply-To: <xmqqsegev4jp.fsf@gitster.g>

On Mon, Sep 22, 2025 at 09:24:26AM -0700, Junio C Hamano wrote:

Show 27 quoted lines

> Patrick Steinhardt <ps@pks.im> writes:
> 
> >> 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.
> 
> Why is it a bad thing?  The official repository can have a README.md
> with a single entry "maintenance releases for Git 2.98 LTS (most
> notably with no Rust requirements) are found at this separate site".

There's a couple reasons:

  - The LTS maintainer may not be as familiar with the Git codebase as
    we are, so they would benefit from the usual processes on the
    mailing list.

  - The LTS maintainer may not be as trusted as other regulars on the
    mailing list are, so we (from my POV) may want to avoid having a
    basically unobserved fork elsewhere.

  - The end result would still be "git", and users will come to us to
    complain about issues in the LTS release.

  - Initial releases of the LTS release branch that are managed by us
    would sit in our repo, whereas subsequent releases would sit in the
    LTS release. This will likely cause confusion.

  - We reduce chances of a hard fork of Git.

So with these in mind I think it would be sensible to keep the LTS release as part of the canonical repository.

> > 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.
> 
> No risk for that as long as we have a single "go there" pointer, right?

It somewhat reduces the risk, true. I still worry a bit about encouraging a hard fork.

Show 8 quoted lines

> > And yes, that probably means that a trusted LTS maintainer should be on
> > git-security@ so that they are aware of upcoming security releases.
> 
> Absolutely.
> 
> And there should be a community of those who are working on helping
> the backporting effort around that LTS maintainer that ensures there
> is no "chaos and a plethora of different LTS releases".

Fair.

Show 15 quoted lines

> We might occasionally update what is listed in "git ls-remote --tags"
> from our repository by syncing with them only for convenience, but
> the important point is that the community supported LTS should have
> its own official site, which is different from the cutting/bleeding
> 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.

It gives the LTS maintainers flexibility, but still makes the canonical repository the single source of truth for Git releases. Furthermore, we'd have a way to double check the results before creating the tags.

Patrick