LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Chris Mason <clm@fb.com>, Johannes Weiner <hannes@cmpxchg.org>,
	Kent Overstreet <kent.overstreet@gmail.com>,
	Matthew Wilcox <willy@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Darrick J. Wong" <djwong@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	David Howells <dhowells@redhat.com>,
	"ksummit@lists.linux.dev" <ksummit@lists.linux.dev>
Subject: Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers Summit topic?
Date: Thu, 16 Sep 2021 15:15:29 -0400	[thread overview]
Message-ID: <YUOX0VxkO+/1kT7u@mit.edu> (raw)
In-Reply-To: <33a2000f56d51284e2df0cfcd704e93977684b59.camel@HansenPartnership.com>

On Thu, Sep 16, 2021 at 01:11:21PM -0400, James Bottomley wrote:
> 
> Actually, I don't see who should ack being an unknown.  The MAINTAINERS
> file covers most of the kernel and a set of scripts will tell you based
> on your code who the maintainers are ... that would seem to be the
> definitive ack list.

It's *really* not that simple.  It is *not* the case that if a change
touches a single line of fs/ext4 (as well as 60+ other filesystems),
for example:

-       ei = kmem_cache_alloc(ext4_inode_cachep, GFP_NOFS);
+       ei = alloc_inode_sb(sb, ext4_inode_cachep, GFP_NOFS);

that the submitter *must* get a ACK from me --- or that I am entitled
to NACK the entire 79 patch series for any reason I feel like, or to
withhold my ACK as hostage until the submitter does some development
work that I want.

What typically happens is if someone were to try to play games like
this inside, say, the Networking subsystem, past a certain point,
David Miller will just take the patch series, ignoring people who have
NACK's down if they can't be justified.  The difference is that even
though Andrew Morton (the titular maintainer for all of Memory
Management, per the MAINTAINERS file), Andrew seems to have a much
lighter touch on how the mm subsystem is run.

> I think the problem is the ack list for features covering large areas
> is large and the problems come when the acker's don't agree ... some
> like it, some don't.  The only deadlock breaking mechanism we have for
> this is either Linus yelling at everyone or something happening to get
> everyone into alignment (like an MM summit meeting).  Our current model
> seems to be every acker has a foot on the brake, which means a single
> nack can derail the process.  It gets even worse if you get a couple of
> nacks each requesting mutually conflicting things.
> 
> We also have this other problem of subsystems not being entirely
> collaborative.  If one subsystem really likes it and another doesn't,
> there's a fear in the maintainers of simply being overridden by the
> pull request going through the liking subsystem's tree.  This could be
> seen as a deadlock breaking mechanism, but fear of this happening
> drives overreactions.
> 
> We could definitely do a clear definition of who is allowed to nack and
> when can that be overridden.

Well, yes.  And this is why I think there is a process issue here that
*is* within the MAINTAINERS SUMMIT purview, and if we need to
technical BOF to settle the specific question of what needs to happen,
whether it happens at LPC, or it needs to happen after LPC, then let's
have it happen.

I'd be really disappointed if we have to wait until December 2022 for
the next LSF/MM, and if we don't get consensus there, ala DAX, that we
then have to wait until late 2023, etc.  As others have said, this is
holding up some work that file system developers would really like to
see.

					- Ted

  reply	other threads:[~2021-09-16 19:16 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 17:42 Theodore Ts'o
2021-09-15 18:03 ` James Bottomley
2021-09-15 18:20   ` Theodore Ts'o
2021-09-15 18:41     ` Chris Mason
2021-09-15 19:15       ` James Bottomley
2021-09-15 20:48         ` Theodore Ts'o
2021-09-16 14:55           ` Kent Overstreet
2021-09-16 13:51         ` David Howells
2021-09-16 16:46         ` Chris Mason
2021-09-16 17:11           ` James Bottomley
2021-09-16 19:15             ` Theodore Ts'o [this message]
2021-09-16 19:26               ` Andrew Morton
2021-09-16 20:16               ` Kent Overstreet
2021-09-17  1:42                 ` Theodore Ts'o
2021-09-17  4:58                   ` Kent Overstreet
2021-09-16 20:38             ` Chris Mason
2021-09-16 21:00               ` Konstantin Ryabitsev
2021-09-17 11:14                 ` James Bottomley
2021-09-17 12:36                   ` Konstantin Ryabitsev
2021-09-17 13:00                     ` James Bottomley
2021-09-17 14:36                       ` Chris Mason
2021-09-16 17:15           ` Kent Overstreet
2021-09-16 22:27             ` Chris Mason

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YUOX0VxkO+/1kT7u@mit.edu \
    --to=tytso@mit.edu \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=clm@fb.com \
    --cc=dhowells@redhat.com \
    --cc=djwong@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hch@infradead.org \
    --cc=kent.overstreet@gmail.com \
    --cc=ksummit@lists.linux.dev \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=torvalds@linux-foundation.org \
    --cc=willy@infradead.org \
    --subject='Re: [MAINTAINER SUMMIT] Folios as a potential Kernel/Maintainers Summit topic?' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).