On Fri, Sep 5, 2025 at 6:38 AM Patrick Steinhardt [off-list ref] wrote:

On Fri, Sep 05, 2025 at 02:45:46PM +0200, Matthias Aßhauer wrote:

quoted

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/ (local), 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/ (local)
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...