Release goals for 22.XX

Ansuel Smith ansuelsmth at gmail.com
Sat Oct 2 13:21:16 PDT 2021


Il giorno sab 2 ott 2021 alle ore 01:35 Rosen Penev <rosenp at gmail.com>
ha scritto:
>
> On Fri, Oct 1, 2021 at 3:05 PM Hauke Mehrtens <hauke at hauke-m.de> wrote:
> >
> > On 9/30/21 10:40 PM, Paul Spooren wrote:
> > >
> > > On 9/30/21 10:01, Nick wrote:
> > >>
> > >> On 9/30/21 21:43, Daniel Golle wrote:
> > >>> On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote:
> > >>>> On 30/09/2021 01:19, Nick wrote:
> > >>>>> On 9/29/21 22:28, Hauke Mehrtens wrote:
> > >>>>>
> > >>>>>> 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 5.15 could be also a LTS Kernel that should be released in the
> > >>>>> end of October? Why not aiming for it if we plan to release in 2022?
> > >>>> This would undoubtedly delay the next release, as we've seen in the
> > >>>> past. We don't even have all targets on 5.10, which was released
> > >>>> roughly
> > >>>> 9 months ago. You do the math. If we target 5.15, I doubt we'll even
> > >>>> see
> > >>>> a release in 2022.
> > >>> I also believe we should do the next release based on Linux 5.10 and
> > >>> try branching still this year (which I believe is realistic to make all
> > >>> targets build with 5.10 till then), so we can target April 2022 as time
> > >>> of release.
> >
> > I agree with you Daniel and think this timeline is reasonable.
> >
> > >> Sounds good, so we can go on with 5.15 when it is released?
> > >
> > > Some targets already moved to 5.10 as default, feel free to add 5.15 as
> > > the new TESTING kernel there.
> >
> > I am against adding support for kernel 5.15 now, we should better wait
> > till after we branched the relase off.
> >
> > >
> > >> I think the most problematic thing is if we want to have DSA support
> > >> for all targets as requirement. Not sure if this is possible.
> > >
> > > It seems fine found a okay'ish middle ground between DSA and non-DSA, so
> > > I'd not make DSA blocking for the next release but continue to integrate
> > > it where ever possible (and stable).
> >
> > I think we will never convert all swconfig drivers to DSA. I do not
> > think anyone will invest the time to write a DSA driver for the ADM6996L
> > chip for example. It could be that we just remove support for the last
> > boards which still use swconfig in some years.
> Not that many look like they can get DSA treatment. With realtek
> switches, only RTL8366RB seems supported upstream. ar8216 can be

Wait. Ar8216 can't be supported for qca8k (extensive rework of the
entire driver.
He has an entirely different scheme. qca8k = ar8326 8337
Do you have a list of the ar8216 devices?

> replaced by qca8k currently but lots of testing is needed. I have no
> idea about mediatek and why it has an swconfig driver when there's a
> DSA one upstream.
> >
> > Hauke
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list