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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 23, 2022 at 4:46 AM Christian Brauner <brauner@xxxxxxxxxx> wrote:
> On Thu, Sep 22, 2022 at 10:57:38AM -0700, Linus Torvalds wrote:
> > On Thu, Sep 22, 2022 at 9:27 AM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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.
> >
> > 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



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux