Reaching out to Greg KH for 6 year LTS kernel versions

[Robert Marko]

On Fri, 12 Aug 2022 at 23:12, Florian Fainelli <f.fainelli at gmail.com> wrote:
>
> On 8/12/22 13:28, Robert Marko wrote:
> > 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.
>
> That is fair, if we are spread too thin, and clearly we are, then yes, I
> agree we should focus on the latest releases and people who cannot
> update for whatever reason, be it now unsupported hardware, or high
> availability or whatever should find out a solution. It's open source
> after all :)
>
>
> >>
> >>
> >>>
> >>>>
> >>>> 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.
>
> Which is an interesting paradox.

Agreed, however that is the conclusion we reached on the IRC after a
long discussion.
Its a compromise that makes both sides equally unhappy.

Regards,
Robert
> --
> Florian