On 10/30/19 9:50 AM, Hauke Mehrtens wrote:
On 10/30/19 5:29 PM, Adrian Schmutzler wrote:
Hi,
-----Original Message-----
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf
Of Hauke Mehrtens
Sent: Mittwoch, 30. Oktober 2019 16:54
To: John Crispin <j...@phrozen.org>; OpenWrt Development List
<openwrt-devel@lists.openwrt.org>
Subject: Re: [OpenWrt-Devel] v5.4 as next kernel
On 10/29/19 6:37 AM, John Crispin wrote:
Hi,
should we use v5.4 as our next kernel ?
John
I also agree to have kernel 5.4 as the next kernel, it will be finally
released in about 1 months and it is a long term kernel. If we are lucky
it will be supported for 6 years for Android.
What do we want to use in the next 20.X release after 19.07?
If we want to go with kernel 5.4 with the release after 19.07 we can not
make this release before April, I would assume. We would have generic
support in OpenWrt master in about 1 month and then we will port the
targets, probably we will have the most important targets ported about
2 months later (Mid January 2020) and can stabilize and port the rest of
afterwards.
hauke
1. We currently have work-in-progress 4.19 support PRs for ramips, ipq806x and
bcm63xx, still with considerable work to do at least for the first two (IIRC).
Without in-depth knowledge, I wonder whether it wouldn't be more efficient to
skip 4.19 for those and go directly to 5.4 (less backporting etc., but also
more adjustments of local stuff).
2. Obviously, starting with 5.4 now will cause a mixed-kernel-release-or-not
debate in early 2020. So, when moving to 5.4 we should already ask ourselves
this question early in the process. (Which obviously also depends on the
decision on subject 1.) I personally favor to not have a mixed kernel release,
but as I'm commenting from the side my voice shouldn't count much in that
process.
3. Since stable branches are typically made 3-6 months after when they have
been set, I wouldn't care too much about a 3 month delay in estimated release
date. :-)
Just wanted to add those thoughts to the discussion, sorry for not providing
answers ;-)
Best
Adrian
Supporting two different kernel versions in one release was not a good
idea, we did it because the release was delayed and we decided to use
kernel 4.14 partially for this release pretty late in the process.
We should decide if we want to use kernel 5.4 in the next release in the
next 2 to 4 weeks, so we do not lose so much time.
I would suggest the following.
1. Sift the 20.X release after 19.07 from January to April 2020
1.1. We will not get kernel 5.4 stable till January
2. Integrate support for kernel 5.4 soon
2.1. The generic support with the first targets should be there in about
1.5 months, which should be doable
3. Migrate all the targets to kernel 5.4
3.1. Probably all the targets on kernel 4.19 will be migrated quickly,
the not so well supported targets could cause problems, but we have
similar problems with kernel 4.19.
4. When no target is using kernel 4.19 any more, drop support for it
4.1. dropping support for kernel 4.19 could cause problems for some
downstream users which would like to use kernel 4.19 (e.g. Intel in
prpl), I do not know if we care.
Hauke
At least in my opinion, and echoed by comments on the forum, OpenWrt
is suffering from a credibility gap due to the delays associated with
the release of 19.01, err, 19.07, amplified by the statements made
after the Hamburg meeting[1].
There are also significant gaps in the ath79 target when it comes to
NAND support. Although AR934X support was just added in 758a4d1766 and
devices that use that "flavor" of NAND are appearing, there still is
no SPI-NAND support (https://github.com/openwrt/openwrt/pull/2184 has
been available for review for nearly four months now) and I am not
aware of work on the Mikrotik devices.
Even though the ar71xx target has been deprecated and announced to be
dropped in the next release, this lack of support has downstream
projects still developing against it as there is no "release" version
on which to base their devices. See, for example
https://github.com/gl-inet/openwrt/commit/cfc85fc80e914a2808f7b19d71c47db24c471cd7
At least if the work on ath79 around NAND is adopted and additional
work (Mikrotik) can proceed on the "familiar" Linux 4.19, it seems
that it would have a greater likelihood of success that if the
transition to Linux 5.4 were thrown into the mix.
To address these issues, I'd suggest:
* Release 19.07 as soon as possible
* Plan for and release 20.01
* On schedule
* With Linux 4.19
* With NAND support as complete as possible for the ath79 target
* Include devices using the AR934X driver
* Adopt https://github.com/openwrt/openwrt/pull/2184
* Encourage porting of the remaining ar71xx/NAND devices to ath79
* Encourage and adopt development of Mikrotik support
* Dropping ar71xx, as agreed at Hamburg
* Give up on "Point release cycle: Every 2 months automatic if there
are any new commits within release branch" until after 20.06
(reality here outweighs product-manager instincts)
* Plan for and release 20.07
* On schedule
* With Linux 5.4
Jeff Kletsky
[1] https://openwrt.org/meetings/hamburg2019/start#decisions
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
