Linux-Fsdevel Archive on
 help / color / Atom feed
From: Allison Collins <>
To: Amir Goldstein <>,
	"Darrick J. Wong" <>
	linux-fsdevel <>,
	xfs <>, Eryu Guan <>,
	Eric Sandeen <>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale
Date: Fri, 31 Jan 2020 20:20:37 -0700
Message-ID: <> (raw)
In-Reply-To: <>

On 1/31/20 12:30 AM, Amir Goldstein wrote:
> On Fri, Jan 31, 2020 at 7:25 AM Darrick J. Wong <> wrote:
>> Hi everyone,
>> I would like to discuss how to improve the process of shepherding code
>> into the kernel to make it more enjoyable for maintainers, reviewers,
>> and code authors.  Here is a brief summary of how we got here:
>> Years ago, XFS had one maintainer tending to all four key git repos
>> (kernel, userspace, documentation, testing).  Like most subsystems, the
>> maintainer did a lot of review and porting code between the kernel and
>> userspace, though with help from others.
>> It turns out that this didn't scale very well, so we split the
>> responsibilities into three maintainers.  Like most subsystems, the
>> maintainers still did a lot of review and porting work, though with help
>> from others.
>> It turns out that this system doesn't scale very well either.  Even with
>> three maintainers sharing access to the git trees and working together
>> to get reviews done, mailing list traffic has been trending upwards for
>> years, and we still can't keep up.  I fear that many maintainers are
>> burning out.  For XFS, the biggest pain point (AFAICT) is not assembly and
>> testing of the git trees, but keeping up with the mail and the reviews.
>> So what do we do about this?  I think we (the XFS project, anyway)
>> should increase the amount of organizing in our review process.  For
>> large patchsets, I would like to improve informal communication about
>> who the author might like to have conduct a review, who might be
>> interested in conducting a review, estimates of how much time a reviewer
>> has to spend on a patchset, and of course, feedback about how it went.
>> This of course is to lay the groundwork for making a case to our bosses
>> for growing our community, allocating time for reviews and for growing
>> our skills as reviewers.
> Interesting.
> Eryu usually posts a weekly status of xfstests review queue, often with
> a call for reviewers, sometimes with specific patch series mentioned.
> That helps me as a developer to monitor the status of my own work
> and it helps me as a reviewer to put the efforts where the maintainer
> needs me the most.
> For xfs kernel patches, I can represent the voice of "new blood".
> Getting new people to join the review effort is quite a hard barrier.
> I have taken a few stabs at doing review for xfs patch series over the
> year, but it mostly ends up feeling like it helped me (get to know xfs code
> better) more than it helped the maintainer, because the chances of a
> new reviewer to catch meaningful bugs are very low and if another reviewer
> is going to go over the same patch series, the chances of new reviewer to
> catch bugs that novice reviewer will not catch are extremely low.
That sounds like a familiar experience.  Lots of times I'll start a 
review, but then someone else will finish it before I do, and catch more 
things along the way.  So I sort of feel like if it's not something I 
can get through quickly, then it's not a very good distribution of work 
effort and I should shift to something else. Most of the time, I'll 
study it until I feel like I understand what the person is trying to do, 
and I might catch stuff that appears like it may not align with that 
pursuit, but I don't necessarily feel I can deem it void of all 
unforeseen bugs.

> However, there are quite a few cleanup and refactoring patch series,
> especially on the xfs list, where a review from an "outsider" could still
> be of value to the xfs community. OTOH, for xfs maintainer, those are
> the easy patches to review, so is there a gain in offloading those reviews?
> Bottom line - a report of the subsystem review queue status, call for
> reviewers and highlighting specific areas in need of review is a good idea.
> Developers responding to that report publicly with availability for review,
> intention and expected time frame for taking on a review would be helpful
> for both maintainers and potential reviewers.
I definitely think that would help delegate review efforts a little 
more.  That way it's clear what people are working on, and what still 
needs attention.

> Thanks,
> Amir.
>> ---
>> I want to spend the time between right now and whenever this discussion
>> happens to make a list of everything that works and that could be made
>> better about our development process.
>> I want to spend five minutes at the start of the discussion to
>> acknowledge everyone's feelings around that list that we will have
>> compiled.
>> Then I want to spend the rest of the session breaking up the problems
>> into small enough pieces to solve, discussing solutions to those
>> problems, and (ideally) pushing towards a consensus on what series of
>> small adjustments we can make to arrive at something that works better
>> for everyone.
>> --D
>> _______________________________________________
>> Lsf-pc mailing list

  reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  5:25 Darrick J. Wong
2020-01-31  7:30 ` [Lsf-pc] " Amir Goldstein
2020-02-01  3:20   ` Allison Collins [this message]
2020-02-02 21:46     ` Dave Chinner
2020-02-09 17:12       ` Allison Collins
2020-02-12  0:21         ` NeilBrown
2020-02-12  6:58           ` Darrick J. Wong
2020-02-12 22:06         ` Darrick J. Wong
2020-02-12 22:19           ` Dan Williams
2020-02-12 22:36             ` Darrick J. Wong
2020-02-13 15:11           ` Brian Foster
2020-02-13 15:46             ` Matthew Wilcox
2020-02-16 21:55               ` Dave Chinner
2020-02-19  0:29                 ` Darrick J. Wong
2020-02-19  1:17                   ` Theodore Y. Ts'o
2020-02-12 23:39         ` Dave Chinner
2020-02-13 15:19           ` Brian Foster
2020-02-17  0:11             ` Dave Chinner
2020-02-17 15:01               ` Brian Foster
2020-02-12 21:36       ` Darrick J. Wong
2020-02-12 22:42   ` Darrick J. Wong
2020-02-13 10:21     ` Amir Goldstein
2020-02-07 22:03 ` Matthew Wilcox
2020-02-12  3:51   ` Theodore Y. Ts'o
2020-02-12 22:29     ` Darrick J. Wong
2020-02-12 22:21   ` Darrick J. Wong
2020-02-13  1:23     ` Dave Chinner

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \

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

Linux-Fsdevel Archive on

Archives are clonable:
	git clone --mirror linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ \
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone