Reaching out to Greg KH for 6 year LTS kernel versions

[Robert Marko]

On Fri, 12 Aug 2022 at 21:45, Florian Fainelli <f.fainelli at gmail.com> wrote:
>
> On 8/12/22 11:09, Robert Marko wrote:
> > On Fri, 12 Aug 2022 at 19:54, Florian Fainelli <f.fainelli at gmail.com> wrote:
> >>
> >> On 8/10/22 13:32, Robert Marko wrote:
> >>> On Wed, 10 Aug 2022 at 22:30, Philip Prindeville
> >>> <philipp at redfish-solutions.com> wrote:
> >>>>
> >>>> Not to play the devil's advocate but... do we want old kernels hanging out that long?
> >>>>
> >>>> Besides not encouraging people to update to new releases that mitigate discovered CVE's, we'd also not pick up David Taht's excellent improvements in Buffer Bloat.
> >>>
> >>> I have to agree with this.
> >>> What would be the benefit for OpenWrt with having LTS kernels
> >>> supported for 6 years?
> >>
> >> One aspect I could see is take for instance a device that is widely
> >> popular amongst our user base as was TI's ar7 for instance a while back,
> >> and for which we might have done a Linux 5.4, or 5.10 version at the
> >> time but we do not wish to continue to maintain.
> >
> > I dont see how this is related to LTS kernel support.
>
> OK maybe I need to spell out my example more clearly. Let us say that we
> have a release in 2019 of OpenWrt that supported TI AR7 based upon the
> Linux 5.4 kernel.
>
> Fast forward to 2022, we decide to abandon TI AR7 in master and we stop
> supporting it entirely for future releases. A very bad Linux security
> problem show up, and because we care about our users, we keep updating
> the LTS kernel that was used in the 2019.x release up until, say the
> said kernel stops being supported. If that support time frame was 6
> years, then we would really be helping our users.
>
> Maybe the wider discussion to be had, is:
>
> - when and how do we decide to deprecate a given Linux port, I assume it
> is when no more users show up or maybe more realistically when OpenWrt
> developers just cannot keep up with updating those devices because they
> no longer use those themselves
>
> - how long do we want to keep supporting past OpenWrt releases with
> kernel updates, 2 years, 3/4 years, 6 years to match the kernel
> lifecycle they are based upon?

As an idea, I understand this, it would basically be an "LTS" OpenWrt
release that
would receive security-only updates.

However, we had a long discussion on the IRC today and the resources are spread
rather thin even currently with 2 or 3 releases being supported.

If its gonna be a volunteer kind of no guarantees release, then maybe
but I dont see
how we can manage that as well.
>
>
> >
> >>
> >> Being able to continue to deliver stable kernel updates in a stable
> >> OpenWrt branch could be a good way for users to pick up their next xDSL
> >> router since there are not so many out there that can actually run
> >> OpenWrt compared to pure Wired/Wi-Fi for instance.
> >
> > I can agree with this.
> >
> >>
> >>> Backporting stuff is already hard with only 2 LTS versions supported in OpenWrt.
> >>
> >> That argument I am sympathetic with, and the sheer amount of out of tree
> >> patches we have in OpenWrt is not helping, in fact it definitively makes
> >> it harder to regularly test, but still somehow we managed to do it.
> >>
> >> Since we will merge stable updates eventually, the point would be that
> >> instead of testing those that are already released, we could try to test
> >> the release candidates and report back anything we find?
> >
> > This is a good idea, not sure how we can do it within OpenWrt though with
> > the amount of patches we have that make it a pain to bump kernels.
>
> Maybe we should give it a spin and see how painful that actually is and
> then if we can sustain doing that over time it just becomes a thing a
> group of volunteers can do?
>
> After all, we do go through that exercise fairly frequently.

This looks similar to what we discussed to today on IRC, maybe having a more
up-to-date development OpenWrt along longer lasting stable releases.

As currently, OpenWrt is way out of date for kernel development but is moving
too quickly for keeping the stable releases from regressing.

Regards,
Robert
> --
> Florian