On Tue, Apr 16, 2024 at 02:04:14PM -0400, Josef Bacik wrote: > 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. Context here is that some of us discussed this idea off-list a while ago. Various aspects of this sounded appealing to me. One of my crucial points is that the current fs/ maintainers are responsible and will decide on the addition of any new maintainers. As of v6.8 Jan Kara has been added as co-maintainer of fs/. The number of trees merged into vfs/vfs.git has slowly increased. There's already a few people that send pulls and there'll be another tree addition during this cycle. New subtrees are also now formalized in MAINTAINERS similar to other hierarchical trees. New trees that are added and that get sent to fs/ are marked with FILESYSTEMS [subsystem] and we've gotten a few of those last year actually. I'm generally supportive of moving into this direction. But I have no interest in this being decided over the heads of the current fs/ maintainers (or individual filesystem maintainers for that matter). This should be voluntary. Individual fses or subsystems are welcome to send pulls. If there's bigger fses that want to start doing this then a conversations on expectations from both sides needs to happen. If we do this then we start with one or two non-trivial fses and then go from there. And it also needs to work for Linus obviously. Rotating tree management for a cycle seems fine to me once we've reached a point where it's really more than can be handled. Might actually mean one can get some work on something bigger done. Writing pidfs on the side while maintaining was certainly fun. > 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
