On Fri, 12 Aug 2022 at 23:12, Florian Fainelli <f.faine...@gmail.com> wrote: > > On 8/12/22 13:28, Robert Marko wrote: > > On Fri, 12 Aug 2022 at 21:45, Florian Fainelli <f.faine...@gmail.com> wrote: > >> > >> On 8/12/22 11:09, Robert Marko wrote: > >>> On Fri, 12 Aug 2022 at 19:54, Florian Fainelli <f.faine...@gmail.com> > >>> wrote: > >>>> > >>>> On 8/10/22 13:32, Robert Marko wrote: > >>>>> On Wed, 10 Aug 2022 at 22:30, Philip Prindeville > >>>>> <phil...@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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel