Thread (15 messages) 15 messages, 6 authors, 2022-09-23

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

flat view

From: Paul Moore <paul@paul-moore.com>
Date: 2022-09-23 14:42:18
Also in: linux-cifs, linux-fsdevel, linux-integrity

On Fri, Sep 23, 2022 at 4:46 AM Christian Brauner [off-list ref] wrote:
On Thu, Sep 22, 2022 at 10:57:38AM -0700, Linus Torvalds wrote:
quoted
On Thu, Sep 22, 2022 at 9:27 AM Casey Schaufler [off-list ref] wrote:
quoted
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.

It's a bit more work to see them in another order, but I find the
easiest way is actually to just follow the parent links to get the
overview of what is going on (reading just the commit messages), and
then after that you "reverse course" and use the browser back button
to just go the other way while looking at the details of the patches.

And I suspect a lot of people are happier *without* large patch-sets
being posted to the mailing lists when most patches aren't necessarily
at all relevant to that mailing list except as context.
The problem is also that it's impossible to please both parties here.
Oh the trials and tribulations of Linux Kernel development! ;)

I'm joking, but I do understand the difficulty of pleasing a large
group of people with very different desires.
A good portion of people doesn't like being flooded with patches they
don't really care about and the other portion gets worked up when they
only see a single patch.
You are obviously never going to be able to make everyone happy, and
everyone with a solution to share obviously has some bias (I'm
definitely including myself in this statement), but I tend to fall
back on the idea that upstream kernel development has always required
those involved to deal with a large amount of email, so sending a full
patchset is not new.
So honestly I just always make a judgement call based on the series. But
b4 makes it so so easy to just retrieve the whole series. So even if I
only receive a single patch and am curious then I just use b4.
As I mentioned previously in this thread, the issue is more on the
reply side.  Reading from lore or b4 isn't terrible for me, but
replying is a pain for me and my mail setup.
I've even got it integrated into mutt directly:
I'm glad it works for you.  Although I would like to take this
opportunity to remind anyone still following this tangent that not
everyone uses mutt, some of us* really dislike it, but due to the
magic of email we are still able to participate with other mail
clients, services, and tools.

* I'm using "us" somewhat liberally here, I have no data to back up my
claims.  However, I'm fully prepared to accept the idea that I'm the
only person out of the thousands of kernel devs who dislikes mutt.
Bring it on haters, just know that you're all wrong ;)

-- 
paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help