[OpenWrt-Devel] v5.4 as next kernel

[Jeff Kletsky]

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-bounces at lists.openwrt.org] On Behalf Of Hauke Mehrtens
>>> Sent: Mittwoch, 30. Oktober 2019 16:54
>>> To: John Crispin <john at phrozen.org>; OpenWrt Development List <openwrt-devel at 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 at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel