On Fri, Sep 5, 2025 at 6:38 AM Patrick Steinhardt <ps@xxxxxx> 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@xxxxxxxxxxxxxx/ 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...
