Re: [RFC PATCH 00/29] acl: add vfs posix acl api

[Christian Brauner <brauner@kernel.org>]

On Thu, Sep 22, 2022 at 06:13:44PM -0400, Paul Moore wrote:
> On Thu, Sep 22, 2022 at 5:57 PM Serge E. Hallyn <serge@hallyn.com> wrote:
> > On Thu, Sep 22, 2022 at 03:07:44PM -0400, Paul Moore wrote:
> > > On Thu, Sep 22, 2022 at 2:54 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > > On 9/22/2022 10:57 AM, Linus Torvalds wrote:
> > > > > On Thu, Sep 22, 2022 at 9:27 AM Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > > >> Could we please see the entire patch set on the LSM list?
> > > > > While I don't think that's necessarily wrong, I would like to point
> > > > > out that the gitweb interface actually does make it fairly easy to
> > > > > just see the whole patch-set.
> > > > >
> > > > > IOW, that
> > > > >
> > > > >   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/idmapping.git/log/?h=fs.acl.rework
> > > > >
> > > > > that Christian pointed to is not a horrible way to see it all. Go to
> > > > > the top-most commit, and it's easy to follow the parent links.
> > > >
> > > > I understand that the web interface is fine for browsing the changes.
> > > > It isn't helpful for making comments on the changes. The discussion
> > > > on specific patches (e.g. selinux) may have impact on other parts of
> > > > the system (e.g. integrity) or be relevant elsewhere (e.g. smack). It
> > > > can be a real problem if the higher level mailing list (the LSM list
> > > > in this case) isn't included.
> > >
> > > This is probably one of those few cases where Casey and I are in
> > > perfect agreement.  I'd much rather see the patches hit my inbox than
> > > have to go hunting for them and then awkwardly replying to them (and
> > > yes, I know there are ways to do that, I just personally find it
> > > annoying).  I figure we are all deluged with email on a daily basis
> > > and have developed mechanisms to deal with that in a sane way, what is
> > > 29 more patches on the pile?
> >
> > Even better than the web interface, is find the message-id in any of the
> > emails you did get, and run
> >
> > b4 mbox 20220922151728.1557914-1-brauner@kernel.org
> >
> > In general I'd agree with sending the whole set to the lsm list, but
> > then one needs to start knowing which lists do and don't want the whole
> > set...  b4 mbox and lei are now how I read all kernel related lists.
> 
> In my opinion, sending the entire patchset to the relevant lists
> should be the default for all the reasons mentioned above.  All the
> other methods are fine, and I don't want to stop anyone from using
> their favorite tool, but *requiring* the use of a separate tool to
> properly review and comment on patches gets us away from the
> email-is-universal argument.  Yes, all the other tools mentioned are
> still based in a world of email, but if you are not emailing the
> relevant stakeholders directly (or indirectly via a list), you are
> placing another hurdle in front of the reviewers by requiring them to
> leave their email client based workflow and jump over to lore, b4,
> etc. to review the patchset.
> 
> The lore.kernel.org instance is wonderful, full stop, and the b4 tool
> is equally wonderful, full stop, but they are tools intended to assist
> and optimize; they should not replace the practice of sending patches,
> with the full context, to the relevant parties.

I'm happy to send all of v2 to the security mailing list.

But for v1 could you compromise and just use b4?

b4 mbox 20220922151728.1557914-1-brauner@kernel.org

This would mean you could provide reviews for v1 and we don't need to
fragment the v1 discussion because of a resend to include a mailing list.