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.
--
Florian
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
