linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
	xfs <linux-xfs@vger.kernel.org>,
	Eric Sandeen <sandeen@redhat.com>, Eryu Guan <guaneryu@gmail.com>
Subject: Re: [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale
Date: Fri, 7 Feb 2020 14:03:33 -0800	[thread overview]
Message-ID: <20200207220333.GI8731@bombadil.infradead.org> (raw)
In-Reply-To: <20200131052520.GC6869@magnolia>

On Thu, Jan 30, 2020 at 09:25:20PM -0800, Darrick J. Wong wrote:
> 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.

I think the LSFMMBPF conference is part of the problem.  With the best of
intentions, we have set up a system which serves to keep all but the most
dedicated from having a voice at the premier conference for filesystems,
memory management, storage (and now networking).  It wasn't intended to
be that way, but that's what has happened, and it isn't serving us well
as a result.

Three anecdotes.  First, look at Jason's mail from earlier today:
https://lore.kernel.org/linux-mm/20200207194620.GG8731@bombadil.infradead.org/T/#t

There are 11 people on that list, plus Jason, plus three more than I
recommended.  That's 15, just for that one topic.  I think maybe half
of those people will get an invite anyway, but adding on an extra 5-10
people for (what I think is) a critically important topic at the very
nexus of storage, filesystems, memory management, networking and graphics
is almost certainly out of bounds for the scale of the current conference.

Second, I've had Outreachy students who have made meaningful contributions
to the kernel.  Part of their bursary is a travel grant to go to a
conference and they were excited to come to LSFMM.  I've had to tell
them "this conference is invite-only for the top maintainers; you can't
come".  They ended up going to an Open Source Summit conference instead.
By excluding the people who are starting out, we are failing to grow
our community.  I don't think it would have hurt for them to be in the
room; they were unlikely to speak, and perhaps they would have gone on
to make larger contributions.

Third, I hear from people who work on a specific filesystem "Of the
twenty or so slots for the FS part of the conference, there are about
half a dozen generic filesystem people who'll get an invite, then maybe
six filesystems who'll get two slots each, but what we really want to
do is get everybody working on this filesystem in a room and go over
our particular problem areas".

This kills me because LSFMM has been such a critically important part of
Linux development for over a decade, but I think at this point it is at
least not serving us the way we want it to, and may even be doing more
harm than good.  I think it needs to change, and more people need to
be welcomed to the conference.  Maybe it needs to not be invite-only.
Maybe it can stay invite-only, but be twice as large.  Maybe everybody
who's coming needs to front $100 to put towards the costs of a larger
meeting space with more rooms.

Not achievable for this year, I'm sure, but if we start talking now
maybe we can have a better conference in 2021.

  parent reply	other threads:[~2020-02-07 22:03 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  5:25 [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale Darrick J. Wong
2020-01-31  7:30 ` [Lsf-pc] " Amir Goldstein
2020-02-01  3:20   ` Allison Collins
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 [this message]
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:
  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=20200207220333.GI8731@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=darrick.wong@oracle.com \
    --cc=guaneryu@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=sandeen@redhat.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).