Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
MIME-Version: 1.0
References: <20231027130320.69469330@canb.auug.org.au> <CAHC9VhQ+Nt7CrLxSZcOVNEtAypruOmM0ST0P0JJMrOq4XYmAkw@mail.gmail.com>
 <4b4eb40c-b65a-46e2-9e23-5412a9cdcad0@canonical.com> <CAHC9VhQbxJ4-z4Hp7CSmtcTNOWGFeQF2eEyct9=nHCMN_89YXw@mail.gmail.com>
 <20231031074649.3bdbec45@canb.auug.org.au> <CAHC9VhR=x7qB3gmQg+GPYLnXtGU88S3KCiZGjRYtDKSJHp4P1g@mail.gmail.com>
 <20231106101434.70c62773@canb.auug.org.au>
In-Reply-To: <20231106101434.70c62773@canb.auug.org.au>
From:   Paul Moore <paul@paul-moore.com>
Date:   Sun, 5 Nov 2023 18:36:49 -0500
Message-ID: <CAHC9VhQkUVCAboT78M3g6LabmzFqKYdsxMHQ7ePETJKnzDiV+Q@mail.gmail.com>
Subject: Re: linux-next: manual merge of the apparmor tree with the security tree
To:     Stephen Rothwell <sfr@canb.auug.org.au>
Cc:     John Johansen <john.johansen@canonical.com>,
        Casey Schaufler <casey@schaufler-ca.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux Next Mailing List <linux-next@vger.kernel.org>,
        linux-security-module@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Sun, Nov 5, 2023 at 6:14=E2=80=AFPM Stephen Rothwell <sfr@canb.auug.org.=
au> wrote:
>
> Hi Paul,
>
> [Sorry for the slow reply]
>
> On Mon, 30 Oct 2023 17:04:01 -0400 Paul Moore <paul@paul-moore.com> wrote=
:
> >
> > On Mon, Oct 30, 2023 at 4:46=E2=80=AFPM Stephen Rothwell <sfr@canb.auug=
.org.au> wrote:
> > >
> > > On Mon, 30 Oct 2023 12:52:50 -0400 Paul Moore <paul@paul-moore.com> w=
rote:
> > > >
> > > > On Sun, Oct 29, 2023 at 5:09=E2=80=AFPM John Johansen <john.johanse=
n@canonical.com> 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 L=
SM
> > > > syscall patches and I expect the vast majority of these conflicts t=
o
> > > > disappear, although I'm sure we'll pick up some new ones with the r=
est
> > > > 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.

--=20
paul-moore.com