[LSF/MM/BPF TOPIC] Changing how we do file system maintenance

[Josef Bacik <josef@toxicpanda.com>]

Hello,

There have been a few common themes that have come up over the years that I feel
like we should address.

1. Adding new file systems.  This is a long and painful process, and I think it
   should be more painful in order to encourage more FUSE use cases.  However, a
   lot of the reason it's painful is because it's a "send to Linus and see what
   happens" sort of process.  Obviously a lot of us get a say, but there's a
   sort of arbitrary point where it becomes "well send a PR to Linus and see
   what he thinks."  This is annoying for people who review stuff who may have
   legitimate concerns, and it's annoying for new file systems who aren't sure
   what feedback they're supposed to take seriously and what feedback is safe to
   ignore.

2. Removing file systems.  We've gotten some good guidance from Greg and others
   on this, but this still becomes a thing where nobody feels particularly
   empowered to send the first patch of actually removing a file system.  In
   super obvious cases it's easier, but there's a lot of non-obvious cases where
   we kind of sit here and talk about it without doing anything.

3. API changes.  Sometimes we make API changes in the core code and then
   provided helpers for the other file systems to use until they're converted,
   and that long tail goes on forever.  We generally avoid doing work that
   touches all the file systems because we have to coordinate with at least 4
   major trees. I'm particularly guilty of this one, I didn't even notice when
   the new mount API went in, and then I wasn't sufficiently motivated to work
   on it until it intersected with some other work I was doing.  I was easily
   halfway through the work when I found out that Christian had done all of the
   work for us previously, which brings me to #4.

4. We all have our own ways of doing things, but we're all really similar at the
   same time.  In btrfs land we prefer small, bitesize patches.  This makes it
   easier for review, easier for bisecting, etc.  This exists because we take in
   3x the number of changes as any other file system, we have been bitten
   several times by some 6'4" jackass with a swearing problem with a 6000 line
   patch with an unhelpful changelog.  I've had developers get frustrated with
   our way of running our tree because it's setup differently than others. At
   the end of the day however a lot of our policies exist to make it as easy as
   possible for everybody involved to understand what is going on, and to make
   sure we don't repeat previous mistakes.  At the same time we all do a lot of
   the same things, emphasize patch review and testing.

There are other related problems, but these are the big ones as I see them.

I would like to propose we organize ourselves more akin to the other large
subsystems.  We are one of the few where everybody sends their own PR to Linus,
so oftentimes the first time we're testing eachothers code is when we all rebase
our respective trees onto -rc1.  I think we could benefit from getting more
organized amongst ourselves, having a single tree we all flow into, and then
have that tree flow into Linus.

I'm also not a fan of single maintainers in general, much less for this large of
an undertaking.  I would also propose that we have a maintainership group where
we rotate the responsibilities of the mechanics of running a tree like this.
I'm nothing if not unreliable so I wouldn't be part of this group per se, but I
don't think we should just make Christian do it.  This would be a big job, and
it would need to be shared.

I would also propose that along with this single tree and group maintainership
we organize some guidelines about the above problems and all collectively agree
on how we're going to address them.  Having clear guidelines for adding new file
systems, clear guidelines for removing them.  Giving developers the ability to
make big API changes outside of the individual file systems trees to make it
easier to get things merged instead of having to base against 4 or 5 different
trees.  Develop some guidelines about how we want patches to look, how we want
testing to be done, etc. so people can move through our different communities
and not have drastically different experiences.

This is a massive proposal, and not one that we're going to be able to nail down
and implement quickly or easily.  But I think in the long term it'll make
working in our community simpler, more predictable, and less frustrating for
everybody.  Thanks,

Josef