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
