From: Patrick Steinhardt <ps@pks.im>
Date: Mon, 08 Sep 2025 06:42:37 GMT
Subject: Re: [PATCH RFC v2 5/7] BreakingChanges: announce Rust becoming mandatory
Message-ID: <aL563ZzHK-43YeCi@pks.im>
In-Reply-To: <CABPp-BFw-Oqp71jW5SYCKYOWtjWFSQPOsUVWdF7EnzftwAR2vw@mail.gmail.com>

On Sat, Sep 06, 2025 at 10:31:07PM -0700, Elijah Newren wrote:
> On Fri, Sep 5, 2025 at 6:38 AM Patrick Steinhardt <ps@pks.im> wrote:
> >
> > On Fri, Sep 05, 2025 at 02:45:46PM +0200, Matthias Aßhauer wrote:
> 
> > > Do we want to commit to promising support until gccrs is ready? What if
> > > gccrs ends up abandoned? Or takes an unexpectedly long time to reach a stage
> > > where it can build Git? It might make sense to give this LTS release a time
> > > limit instead, or in addidtion.
> >
> > Yeah, I wasn't quite clear on that one, either. An alternative:
> >
> >   - We will maintain the LTS release for 8 release cycles, which equates
> >     to roughly two years. It sounds like a lot, but recent security
> >     releases have stretched quite far into the past.
> >
> >   - If there are still dependents after these two years we will hand
> >     over maintainership of the LTS branch to dependents. So they will be
> >     responsible for the backporting.
> >
> > This really only is a suggestion though. I'm especially waiting for
> > Junio's feedback here to see whether he thinks that this is a reasonable
> > thing to do.
> 
> Over at https://lore.kernel.org/git/xmqqplc43o7c.fsf@gitster.g/, Junio
> said multiple years isn't something he's willing to promise, but
> suggests 18 months might be doable.
> 
> I have a suspicion that if you want a promised level of support,
> you'll not only get something less than what distributors want, but
> something far less than we'll provide in practice.  I'm curious if the
> alternative wording over at
> https://lore.kernel.org/git/CABPp-BG3Zcw63vNziy86MvYNubefn1SmPvXefpqpA=a+42KT8A@mail.gmail.com/
> is more likely to be realistic:
> 
> "We'll weigh the severity of each security issue and the cost to
> backport and give the last C-only version significant extra weight in
> our considerations"
> 
> I know it may not be what distributors want, but overpromising also
> has deleterious effects, so...

I think at least for the security releases we should promise to handle
those. I do not think it's sensible to have a release branch that is
still officially supported, but that contains known vulnerabilities.

Historically this wasn't too much of a problem, either. We always aim to
keep security fixes as minimal as possible, which also helps with the
backporting process. Our last security release for example even spanned
over 8 releases, so if that's anything to go by we even underpromise :)

Patrick