On Sun, Nov 5, 2023 at 6:14 PM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > Hi Paul, > > [Sorry for the slow reply] > > On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > On Mon, Oct 30, 2023 at 4:46 PM Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote: > > > > > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > > > > > > > > On Sun, Oct 29, 2023 at 5:09 PM John Johansen <john.johansen@xxxxxxxxxxxxx> wrote: > > > > > > > > > > is part of the Three basic syscalls series, the plan is still to have that > > > > > series bake in next for a full cycle? > > > > > > > > Yes, that's still the plan. Once v6.7-rc1 is out I'll rebase the LSM > > > > syscall patches and I expect the vast majority of these conflicts to > > > > disappear, although I'm sure we'll pick up some new ones with the rest > > > > of the v6.7-rcX cycle :) > > > > > > These patches should not be in linux-next until after v6.7-rc1. > > > > What if we wanted additional testing beyond the typical? Do you not > > support that? > > No, I try hard not to. It just complicates things when I and others > have to cope with conflicts and build problems caused by > patches/features destined for next+1 while trying to stabilise the > current/next release. The LSM, SELinux, and audit dev-staging branches will no longer flow into the next branches, and I've reset the current lsm/next branch so this should not be an issue the next time you pull. > Sometimes it happens that a feature slips after being added to -next, > but please don't do it deliberately. -- paul-moore.com
