Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi Bjørn, Jo-Philipp, Eric, all of you are right, I think. I didn't make clear what I'd like to see OpenWrt achieve. Cuts need to be done when they delay a release too long or when the reasons are not under the OpenWrt developer's control, but when there is the chance that someone is getting motivated to do it, delay it. After a due date, cut it and release the rest with a lack for a specific feature and other people might get motivated, but that is the last resort. Personally I think one release a year is enough, except when there are critical security issues which deserve an own release, but that is another topic. Regards, Vincent On 10.04.2019 06:04, Eric Luehrsen wrote: > Or that is $0.023647, anyway. :-) > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Or that is $0.023647, anyway. :-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On 4/9/19 7:53 AM, Vincent Wiemann wrote: Hi Bjørn, routers are critical infrastructure. We should try to achieve the best we can. One of the reasons for the Lede split was that problems were procrastinated and accumulated over the release timeline. That's the reason why we should release less often, but with a higher quality. If problems delay a release that is a sign of taking responsibility. Some time ago a friend of mine told me that they have a problem with tickets that nobody wants to take care of. I told him when those tickets appear he should automatically assign them to all people with highest priority after a due date even if it is a minor issue. Productivity has increased rapidly since then. If a device is not supported in a specific release, that might give someone the stimulus to sit down and get this device working again. E.g. many devices have a partition layout on which a bigger kernel does not fit. It is possible to change the partition layout in most cases requiring a modification of the U-Boot boot environment variable. So hard it sounds unfortunately someone needs to be urged to do it. It's the same with porting ar71xx to ath79... When we stop generating ar71xx images some device owners wonder why there is no new release for it. They become aware that they need to sort of add support for this device as if it was a new device support and they might do it. Urging is a bad word, but we need to motivate people to do changes which are not of the fun kind or we might end up in a mess again. Regards, Vincent Wiemann On 09.04.2019 11:02, Bjørn Mork wrote: Jo-Philipp Wich writes: Is there any kind of "official" roadmap/checklist available what "needs" to be done? not that I am aware of, but from the top of my head: - make sure all targets are ported properly to 4.14 - disable all devices which cannot cannot handle the increased kernel size anymore - drop all targets which are not ported to 4.14 - fix important open issues in the tracker Apologies if this is out of line... I just fealt the urge to post my personal opinion, FWIW. It seems to me that you are setting way too high standards for yourselves. From my point of view, the OpenWrt master branch is almost always in a releasable state. The OpenWrt development and review process ensures an extremely high quality, even for targets which are considered WiP. There are very few days over the last 6 months where you could not have decided to cut a release branch, and got away with it. It's something to be proud of! But you need to tell the rest of the world that you are proud of this by making releases. You should accept that the targets which are ported properly to 4.14 defines "all targets" for the next release. It's not the other way round. Any remaining targets which can be expected to be ported to 4.14 or later, if any, can and should be deferred for a later release. Note that accepting this means that there could be a "next release" in 2019 too... You should also accept that there will be unfixed important open issues at all times. You can't fix them all. To make a release, these issues will either have to be - ignored for that release, - demoted to less important. or - removed by removing the feature/target/whatever is affected by the issue from the release Look at the Debian "release critical" bug handling. It's not really about fixing all the RC bugs, but dealing with them. I realize that actually making a release is real work too, and that this has to take some time after making the initial cut. But delaying the cut for the master branch to get in an even "more ready" state is not really helping... Just my .021 € (considering inflation) Bjørn Hi Bjorn, I agree with you on this one. New OpenWrt adopted a different working model from LEDE. That is staging trees and more careful testing before actual master commits. Long ago are the days when someone thought they were special, commit without review, and just blow up the nightly builds. OpenWrt should release regularly and it should be an editing (cutting) event. Target not on envisioned kernel, cut. Package not core and sketchy, cut. What's left is pretty good. With a variety of targets and volunteer support team bugs will happen. You can test to high confidence, but in such situations nothing is 100%. Instead, you just need to be prepared to deal with them in a timely matter. Just my $0.018649 exchanged at 20190410 04:00 Eric ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi Bjørn, routers are critical infrastructure. We should try to achieve the best we can. One of the reasons for the Lede split was that problems were procrastinated and accumulated over the release timeline. That's the reason why we should release less often, but with a higher quality. If problems delay a release that is a sign of taking responsibility. Some time ago a friend of mine told me that they have a problem with tickets that nobody wants to take care of. I told him when those tickets appear he should automatically assign them to all people with highest priority after a due date even if it is a minor issue. Productivity has increased rapidly since then. If a device is not supported in a specific release, that might give someone the stimulus to sit down and get this device working again. E.g. many devices have a partition layout on which a bigger kernel does not fit. It is possible to change the partition layout in most cases requiring a modification of the U-Boot boot environment variable. So hard it sounds unfortunately someone needs to be urged to do it. It's the same with porting ar71xx to ath79... When we stop generating ar71xx images some device owners wonder why there is no new release for it. They become aware that they need to sort of add support for this device as if it was a new device support and they might do it. Urging is a bad word, but we need to motivate people to do changes which are not of the fun kind or we might end up in a mess again. Regards, Vincent Wiemann On 09.04.2019 11:02, Bjørn Mork wrote: > Jo-Philipp Wich writes: > >>> Is there any kind of "official" roadmap/checklist available what "needs" >>> to be done? >> >> not that I am aware of, but from the top of my head: >> >> - make sure all targets are ported properly to 4.14 >> - disable all devices which cannot cannot handle the increased kernel >> size anymore >> - drop all targets which are not ported to 4.14 >> - fix important open issues in the tracker > > Apologies if this is out of line... I just fealt the urge to post my > personal opinion, FWIW. > > It seems to me that you are setting way too high standards for > yourselves. From my point of view, the OpenWrt master branch is almost > always in a releasable state. The OpenWrt development and review process > ensures an extremely high quality, even for targets which are considered > WiP. There are very few days over the last 6 months where you could not > have decided to cut a release branch, and got away with it. It's > something to be proud of! But you need to tell the rest of the world > that you are proud of this by making releases. > > You should accept that the targets which are ported properly to 4.14 > defines "all targets" for the next release. It's not the other way > round. Any remaining targets which can be expected to be ported to 4.14 > or later, if any, can and should be deferred for a later release. Note > that accepting this means that there could be a "next release" in 2019 > too... > > You should also accept that there will be unfixed important open issues > at all times. You can't fix them all. To make a release, these issues > will either have to be > - ignored for that release, > - demoted to less important. or > - removed by removing the feature/target/whatever is affected by the >issue from the release > > Look at the Debian "release critical" bug handling. It's not really > about fixing all the RC bugs, but dealing with them. > > I realize that actually making a release is real work too, and that this > has to take some time after making the initial cut. But delaying the > cut for the master branch to get in an even "more ready" state is not > really helping... > > Just my .021 € (considering inflation) > > > Bjørn > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On 3/21/19 11:56 AM, Jo-Philipp Wich wrote: > Hi, > >> Is there any kind of "official" roadmap/checklist available what "needs" >> to be done? > > not that I am aware of, but from the top of my head: > > - make sure all targets are ported properly to 4.14 The following targets are still on 4.9: * ar7 * at91 I saw some patches for at91 on the mailing list and Sandeep from Microchip promised to send some new patches. * ixp4xx * orion The following targets are still on 3.18: * adm5120 * adm8668 * au1000 * mcs814x * omap24xx (4.1) * ppc40x * ppc44x * xburst I would not consider any of these targets important and release blocking. Are there any big regressions known for any target which is ported to 4.14? > - disable all devices which cannot cannot handle the increased kernel > size anymore It would be nice to have a build with LuCi enabled, I saw that sometimes the rootfs partition is getting too big. > - drop all targets which are not ported to 4.14 I will send a patch removing support for kernel 3.18 and all the targets which uses it soon, if you need one of them please port them, to kernel 4.14. > - fix important open issues in the tracker > > ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, "ported properly" is rather vague, ipq* are the only "active" platforms the I would classify as troublesome and don't seem to be fixable in 4.14 within resonable time otherwise the list I compiled seems like a pretty resonable one? Best regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, > Is there any kind of "official" roadmap/checklist available what "needs" > to be done? not that I am aware of, but from the top of my head: - make sure all targets are ported properly to 4.14 - disable all devices which cannot cannot handle the increased kernel size anymore - drop all targets which are not ported to 4.14 - fix important open issues in the tracker ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, Is there any kind of "official" roadmap/checklist available what "needs" to be done? Best regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On 2/25/19 11:25 AM, Sven Eckelmann wrote:
On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote:
Mesh is broken using ath10k-ct?
https://bugs.openwrt.org/index.php?do=details_id=2123
[...]
* The "classic" drivers/firmware fail on or after the indicated commit
CONFIG_PACKAGE_ath10k-firmware-qca9887=y
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
That the CT drivers/firmware don't support 802.11s mesh
isn't really an OpenWrt issue.
That there is a regression in overall system capability
that "kills" connectivity is a signficant concern.
* Can you confirm that it works with ath10k-ct but not with ath10k?
* And can you confirm that changing encryption to none has no effect on the
problem.
* Can you confirm that reverting commit cd93b83ad927 ("ath10k: support for
multicast rate control") [1] in ath10k fixes this problem?
* Can you confirm that manually setting mcast_rate to 18000 in the mesh wifi-
iface fixes the problem?
config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option mcast_rate '18000'
option encryption 'none'
* can you confirm that it lo
Testing performed off `master` [1] on a mesh of Archer C7v2 units and
one "test" unit.
* Setting `option mcast_rate '18000'` allows the mesh to connect and
ping for ath10k "classic"
* https://github.com/openwrt/openwrt/pull/1861 allows the mesh to
connect and ping for ath10k "classic"
* ath10k-ct drivers/firmware continue to be unable to support 802.11s on
5 GHz on the Archer C7v2
* The output of `iw phy` is ambiguous on mesh support for the CT
drivers/firmware for 5 GHz phy
* `Supported interface modes:` includes `* mesh point`
* `valid interface combinations:` seems to contradict
* `* #{ managed, P2P-client } <= 16, #{ P2P-GO } <= 3, #{
AP } <= 7, #{ IBSS } <= 1,`
Additional information at
https://github.com/openwrt/openwrt/pull/1861 -- shows significant
benefit "classic"
https://github.com/openwrt/openwrt/pull/1862 -- "CT" drivers/firmware
Additional testing available on (reasonable) request
Jeff Kletsky
[1] "Current" builds based off
commit fe90e48c39c46b3c253b65f38e392c43f6abe2f0 (openwrt/master,
openwrt/HEAD, master)
Author: Piotr Dymacz
Date: Tue Feb 26 13:04:54 2019 +0100
Previous reference points and other units are off master, at or prior to
commit b14289354adb1f07dc9904bfdbc43e6b0bf17a92 (tag: 80211s-good)
Author: John Crispin
Date: Wed Sep 5 14:51:44 2018 +0200
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, AP WDS is currently broken on ath10k-ct (possibly ath10k too), it would be nice to get this PR merged for 19.03 release: https://github.com/openwrt/openwrt/pull/1640 Best Regards, Mantas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On Monday, 25 February 2019 20:25:25 CET Sven Eckelmann wrote: > On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote: > > >> Mesh is broken using ath10k-ct? > > >> https://bugs.openwrt.org/index.php?do=details_id=2123 [...] > Can you check if following works for you (add it as patch to > package/kernel/mac80211/patches/ath/ and hope that my MUA didn't > reformat the patch): Or better test the PRs [1,2] which incorporate a proposed patch [3] from Pradeep. Kind regards, Sven [1] https://github.com/openwrt/openwrt/pull/1861 [2] https://github.com/openwrt/openwrt/pull/1862 [3] https://patchwork.kernel.org/patch/10723033/ signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On Monday, 25 February 2019 15:08:15 CET Jeff Kletsky wrote:
> >> Mesh is broken using ath10k-ct?
> >> https://bugs.openwrt.org/index.php?do=details_id=2123
[...]
> * The "classic" drivers/firmware fail on or after the indicated commit
>
> CONFIG_PACKAGE_ath10k-firmware-qca9887=y
> CONFIG_PACKAGE_kmod-ath10k=y
> # CONFIG_PACKAGE_kmod-ath10k-ct is not set
>
>
> That the CT drivers/firmware don't support 802.11s mesh
> isn't really an OpenWrt issue.
>
> That there is a regression in overall system capability
> that "kills" connectivity is a signficant concern.
* Can you confirm that it works with ath10k-ct but not with ath10k?
* And can you confirm that changing encryption to none has no effect on the
problem.
* Can you confirm that reverting commit cd93b83ad927 ("ath10k: support for
multicast rate control") [1] in ath10k fixes this problem?
* Can you confirm that manually setting mcast_rate to 18000 in the mesh wifi-
iface fixes the problem?
config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option mcast_rate '18000'
option encryption 'none'
* can you confirm that it lo
It looks for me like mac80211 is trying to set the mcast_rate which is
interpreted by ath10k in ath10k_bss_info_changed as 11 Mbit/s (CCK). Which is
of course not supported on 5GHz. So all your pretty little broadcast/multicast
packets end up in nirvana.
Problem here is that rateidx is -1. Which means that it cannot just programmed
up by us.
Can you check if following works for you (add it as patch to
package/kernel/mac80211/patches/ath/ and hope that my MUA didn't
reformat the patch):
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index b73c23d4ce86..85c6d820e8c4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5778,6 +5778,10 @@ static void ath10k_bss_info_changed(struct ieee80211_hw
*hw,
band = def.chan->band;
rateidx = vif->bss_conf.mcast_rate[band] - 1;
+ /* fallback to lowest rate when mcast_rate == -1 */
+ if (rateidx < 0)
+ rateidx = 0;
+
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
rateidx += ATH10K_MAC_FIRST_OFDM_RATE_IDX;
Kind regards,
Sven
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=cd93b83ad927b2c7979e0add0343ace59328b461
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On 2/25/19 5:32 AM, Steve Brown wrote: On Mon, 2019-02-25 at 12:10 +0100, Daniel Engberg wrote: Hi, Mesh is broken using ath10k-ct? https://bugs.openwrt.org/index.php?do=details_id=2123 The combination of ath10k-ct and firmware ver 10.2.4-1.0-00043 works on my QCA9880 (tp-link archer a7 v5). According to debugfs, ath10k/wmi_services claims the ath10k-ct firmware (10.1-ct-8x-__fW-022-1bbfa151) doesn't support mesh. "WMI_SERVICE_MESH_11S -" Steve Two pieces of breakage there, only the second is the showstopper for me: * The CT drivers/firmware do not support mesh, as confirmed above * The "classic" drivers/firmware fail on or after the indicated commit CONFIG_PACKAGE_ath10k-firmware-qca9887=y CONFIG_PACKAGE_kmod-ath10k=y # CONFIG_PACKAGE_kmod-ath10k-ct is not set That the CT drivers/firmware don't support 802.11s mesh isn't really an OpenWrt issue. That there is a regression in overall system capability that "kills" connectivity is a signficant concern. Jeff ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
On Mon, 2019-02-25 at 12:10 +0100, Daniel Engberg wrote: > Hi, > > > Mesh is broken using ath10k-ct? > https://bugs.openwrt.org/index.php?do=details_id=2123 > The combination of ath10k-ct and firmware ver 10.2.4-1.0-00043 works on my QCA9880 (tp-link archer a7 v5). According to debugfs, ath10k/wmi_services claims the ath10k-ct firmware (10.1-ct-8x-__fW-022-1bbfa151) doesn't support mesh. "WMI_SERVICE_MESH_11S -" Steve ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Can someone check https://github.com/openwrt/openwrt/pull/1637? It works well for GCC 8.3, and should work for 7.4 as well. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, Just a few things to take into consideration for 19.XX release Oversized ethernet frames on ipq806x causes crashes https://bugs.openwrt.org/index.php?do=details_id=2026 Overall ethernet performance on ipq806x isn't great, perhaps add a note in the release about it f2fs wonkyness on several (?) platforms? https://github.com/openwrt/openwrt/pull/1575 (scroll down) https://github.com/openwrt/openwrt/pull/1714 USB is half-broken on several devices (ath79) https://forum.openwrt.org/t/ath79-target-status/18614/27 (and below) TL-WDR4900 is currently broken https://github.com/openwrt/openwrt/pull/1773 Zyxel P-2812HNU-F is currently broken https://bugs.openwrt.org/index.php?do=details_id=2124 Mesh is broken using ath10k-ct? https://bugs.openwrt.org/index.php?do=details_id=2123 mac80211: rt2x00: fix crash on release_firmware https://patchwork.ozlabs.org/patch/1047485/ openssl: backport devcrypto changes from master https://patchwork.ozlabs.org/patch/1046426/ openssl: fix devcrypto engine md blocksize https://patchwork.ozlabs.org/patch/1046380/ Make sure NFS v3, v4 and client/server works on release https://bugs.openwrt.org/index.php?do=details_id=2105 Possible performance regressions regarding mt76 https://bugs.openwrt.org/index.php?do=details_id=2090 USB seems to be broken on WRT1900AC v1 https://bugs.openwrt.org/index.php?do=details_id=2091 syscall getrandom() hangs on Turris Omnia https://bugs.openwrt.org/index.php?do=details_id=1979 Worth considering: fstools: Disable lazy init for ext4 overlay https://github.com/openwrt/openwrt/pull/1847 ipset: size optimizations https://github.com/openwrt/openwrt/pull/1852 iputils: update to 20151218 (might be worth jumping to official repo?) https://github.com/openwrt/openwrt/pull/1804 package/libs/libevent: Update to 2.1.9-beta (get 2.1.9 in before branching) https://github.com/openwrt/openwrt/pull/1853 dropbear: bump to 2018.76 (just switch to master/head branch in worst case?) https://github.com/openwrt/openwrt/pull/915 Import the following and make default for ARC: toolchain: Update to GCC 8.3.0 https://github.com/openwrt/openwrt/pull/1846 toolchain/binutils: Add binutils 2.32 https://github.com/openwrt/openwrt/pull/1803 ath79: make TP-Link revision naming consistent https://patchwork.ozlabs.org/patch/1047544/ Might be risky? octeon: Generate writable and ext4 images for ERL https://github.com/openwrt/openwrt/pull/1813 (octeon:) Allow sysupgrade restore on ER https://patchwork.ozlabs.org/patch/1008841/ (octeon:) Evaluate board names in alphabetical order https://patchwork.ozlabs.org/patch/1008838/ There are quite many PRs and patches for adding devices which probably have to wait Best regards, Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWrt 19.03 plans
Hi, thanks for driving this forward. What will be the status of the ath79 target in the release? Will it 1) be held back until the next release or 2) allowed to coexist with ar71xx in the openwrt-19.xx branch as far as it has been developed so far? Best Adrian > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > Behalf Of Hauke Mehrtens > Sent: Freitag, 22. Februar 2019 18:37 > To: LEDE Development List > Subject: [OpenWrt-Devel] OpenWrt 19.03 plans > > Hi, > > We missed January to branching off the next release, but we plan to do > this in March now. ;-) > > The next release is planned to be branched off between 7. and 17. March > and 19.03-rc3 should be released between 2 and 4 weeks later, the final > release will then probably happen sometime in April. > > I think all release critical features we want to have in the next > release are merged, I am not aware of any release critical parts > missing, except probably many bug fixes. > > This release will only use kernel 4.14, the following targets which were > included in the 18.06 release will not be included in the next release > if no one proposes a patch to bring them to kernel 4.14: > * ar7 > * orion > * at91 > > In addition I would like to remove support for kernel 3.18 and move all > targets which still depend on kernel 3.18, to this github repository: > https://github.com/openwrt/targets and remove them from master before > the release. > > Here is the list of targets not on kernel 4.14: > $ grep KERNEL_PATCHVER target/linux/ -r |grep 4.14 -v > target/linux/ar7/Makefile:KERNEL_PATCHVER:=4.9 > target/linux/omap24xx/Makefile:KERNEL_PATCHVER:=4.1 > target/linux/adm5120/Makefile:KERNEL_PATCHVER:=3.18 > target/linux/orion/Makefile:KERNEL_PATCHVER:=4.9 > target/linux/au1000/Makefile:KERNEL_PATCHVER:=3.18 > target/linux/ixp4xx/Makefile:KERNEL_PATCHVER:=4.9 > target/linux/xburst/Makefile:KERNEL_PATCHVER:=3.18 > target/linux/ppc40x/Makefile:KERNEL_PATCHVER:=3.18 > target/linux/adm8668/Makefile:KERNEL_PATCHVER:=3.18 > target/linux/mcs814x/Makefile:KERNEL_PATCHVER:=3.18 > target/linux/at91/Makefile:KERNEL_PATCHVER:=4.9 > target/linux/ppc44x/Makefile:KERNEL_PATCHVER:=3.18 > > Hauke > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel pgpPB7YM0yz6Q.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt 19.03 plans
Hi, We missed January to branching off the next release, but we plan to do this in March now. ;-) The next release is planned to be branched off between 7. and 17. March and 19.03-rc3 should be released between 2 and 4 weeks later, the final release will then probably happen sometime in April. I think all release critical features we want to have in the next release are merged, I am not aware of any release critical parts missing, except probably many bug fixes. This release will only use kernel 4.14, the following targets which were included in the 18.06 release will not be included in the next release if no one proposes a patch to bring them to kernel 4.14: * ar7 * orion * at91 In addition I would like to remove support for kernel 3.18 and move all targets which still depend on kernel 3.18, to this github repository: https://github.com/openwrt/targets and remove them from master before the release. Here is the list of targets not on kernel 4.14: $ grep KERNEL_PATCHVER target/linux/ -r |grep 4.14 -v target/linux/ar7/Makefile:KERNEL_PATCHVER:=4.9 target/linux/omap24xx/Makefile:KERNEL_PATCHVER:=4.1 target/linux/adm5120/Makefile:KERNEL_PATCHVER:=3.18 target/linux/orion/Makefile:KERNEL_PATCHVER:=4.9 target/linux/au1000/Makefile:KERNEL_PATCHVER:=3.18 target/linux/ixp4xx/Makefile:KERNEL_PATCHVER:=4.9 target/linux/xburst/Makefile:KERNEL_PATCHVER:=3.18 target/linux/ppc40x/Makefile:KERNEL_PATCHVER:=3.18 target/linux/adm8668/Makefile:KERNEL_PATCHVER:=3.18 target/linux/mcs814x/Makefile:KERNEL_PATCHVER:=3.18 target/linux/at91/Makefile:KERNEL_PATCHVER:=4.9 target/linux/ppc44x/Makefile:KERNEL_PATCHVER:=3.18 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
