Hauke: My thanks also for writing up those note. My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in.... September. And so on - every six months (or whatever interval we believe we can sustain for the long term.)
For each release, we need to work backwards, and make the feature freeze for the March release in, say, early January so the first RC can come out in January, we can have a few RCs leading up to a final release sometime within 60-75 days. The reasons to do this: - Some people can only use stable releases because of their business needs or their personality. (Or because we tell them "Only Use Stable!") Regular releases let them use the newest features. - Contrarily, a long release cycle "traps" new stuff behind something that "isn't quite done." - We don't waste time producing and testing patched versions of the previous release. There were seven patch releases in the 19.07 series (running from January 2020 through August 2021). A regular release schedule could have avoided many of these. - Having a firm feature freeze date decreases stress. If a particular feature is done/substantially working, it goes in. If it's not quite ready, it can skip this release, and get into the next release. (The alternative is what I think happened with DSA. It was a big change: there were a large number of problems that took a long time to iron out. That kept pushing out the date...) - Customers (our users, our industry partners) gain confidence in projects that can meet their deadlines. Imre noted that "industry is using the snapshots..." but I suspect the extended schedule just worries other vendors. Does this need a vote? Thanks. Rich > On Sep 29, 2021, at 4:28 PM, Hauke Mehrtens <[email protected]> wrote: > > Hi, > > The OpenWrt 21.02 release is done and we should plan the next release. > We already talked about this in the last meeting, see > https://openwrt.org/meetings/20210920 > > To monitor the current state I created this wiki page based on the wiki page > from the previous release: > https://openwrt.org/docs/guide-developer/releases/goals/22.xx > > I would like to get an overview about the "big" changes, if an additional > board is added or something is improved we do not need to plan it. > > I would like to get the following: > > kernel 5.10: > We should get all targets to kernel 5.10. All targets which are not on kernel > 5.10 when we branch off should get removed. > > Kernel version for all targets: > Kernel 5.10 (only): > bmips > Kernel 5.10 (5.4 still present): > bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 > Testing 5.10: > apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta > mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra > Kernel 5.4 only: > arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio > uml zynq > > toolchain: > We already updated the toolchain in master to GCC 11.2, binutils 2.37 and > musl 1.2.2. This looks good to me. Minor version updates of musl libc later > should be ok. gdb and glibc could also be update later if someone wants to do > it. > > mac80211: > I would like to update the mac80211 version we use to match the code from > kernel 5.15 or whatever will be the next LTS kernel. I haven't started yet. > > DSA: > We will migrate some more boards to DSA, the lantiq/xrx200 target is using > DSA in master now. It looks like some boards with qca8k would switch. These > changes should be local to one target or even board anyway. The > infrastructure is already provided. This can continue without much > coordination and we can see what is finished when we branch. > > firewall4: > OpenWrt master contains firewall4 optionally which uses nftables instead of > iptables. It uses the same configuration as firewall3, the old configuration > should still work. Custom iptables extensions should also still work when we > use iptables-nft which supports the iptables user interface and generates > nftables rules, even Debian stable uses iptables-nft by default. Flow > offloading (software and hardware) is supported by upstream kernel when > nftables is used, we are currently using a patch to make it "work" with > iptables too. > > We have to activate it by default and deactivate firewall3. > We probably need some minor modifications to LuCi to show the current > nftables firewall status. This is not device depended like DSA, we can easily > test this on one device and it should work the same way on all others. > > LuCi: > What is still needed in LuCi? > > > Is there anything else which is blocking, should be added or needs a > discussion? > > Hauke > <OpenPGP_0x93DD20630910B515.asc>_______________________________________________ > openwrt-devel mailing list > [email protected] > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
