Pointing the finger at the skills I lack and my inability, while ignoring the wider picture, of the kernel burning out maintainers and not doing well on filesystems.
You get a ton of comments like this because it's true. There are real problems in the kernel, I've seen how hostile it can be to people who are just trying to do the right thing and upstream their changes etc. But your case isn't that. Your behavior would get you in trouble at any job where you have to follow rules set by other people. Your refusal to treat your part of the kernel as anything other than your personal pet project has destroyed your project's potential.
If this was a month or two ago, I would've written something vaguely optimistic here about how you could still turn this around somehow, about what lessons you could learn and move forward with. But that ship has sailed. Your project is no longer the promising next generation filesystem which could replace ext4 as the default choice. Your role is now that of the developer of some small out-of-tree filesystem for a small group of especially interested users. Nobody wanted this for you, including myself. But you have refused to listen to anyone's advice, so now you're here.
Kent has gotten this same feedback across practically every single platform that has discussed his issues. He is unable to take critique and will instead just continue to argue and be combative, therefore proving yet again why he is in this situation in the first place
That's because it is my project, and my responsibility.
I can't be bowing to the demands of any one person; I have to balance the wants and needs of everyone and prioritize shipping something that works above all else.
Repeatedly we've seen that those priorities are not shared, unfortunately.
Arguments are just as heated as they ever were, but now instead of arguing over the actual issues - does this work, are we doing this right - people jump to arguing over language and conduct and demanding apologies or calling for people to be expelled.
But my core mission is just shipping a reliable trustworthy filesystem, and that's what I'm going to stick to.
> But my core mission is just shipping a reliable trustworthy filesystem
You’re very successful at building the file system, but your attempt at shipping it appears to have largely failed. This is a tragic bummer.
Even if working with Linus is hard (and even if he is behaving irrationally), it’s what would’ve allowed you to get bcachefs in hundreds of millions of users’ hands. This seems worthy of a compromise considering all of the work that went into building it. Now almost nobody will be able to use it.
Which hurts so much because it truly seems amazing from so many perspectives, and I admire Kents dedication to it. I was extremely excited to make a large bcachefs filesystem, with RAID6-like redundancy, foreground NVMe disks and spinning rust as background storage, and it seemed to be in the near future too, but now it probably won't happen at all which makes me incredibly sad for us all.
> I can't be bowing to the demands of any one person
This right here is the core of the issue. When you're working as a part of a larger organizational structure, you have to bow down to your boss. When your software is a part of the kernel, it's not your project anymore; it's just one part of Linus's project. You're a contributor, not a leader. Just like I would not control Bcachefs's development process even if I contributed some small but important part to it, you do not control Linux's development process even though you contributed some small but important part to it.
Your core mission is evidently not shipping a reliable trustworthy filesystem. You say that, but your actions speak louder than your words. You know just as well as I do that a filesystem being in-tree rather than out-of-tree makes it significantly more reliable and trustworthy, which is why you chose to get Bcachefs merged into the kernel in the first place. Instead of working within the well-defined boundaries that's necessary to keep Bcachefs in the kernel, you've repeatedly pushed against those boundaries, belittled fellow maintainers, and in general worked hard to make yourself a persona non grata within the kernel community. The predictable outcome is that continued development of Bcachefs will have to happen out-of-tree, and your users won't gain the major reliability and trustworthiness benefits of using an in-tree filesystem. People will warn against using Bcachefs as their root filesystem, since every kernel upgrade will now carry some risk that DKMS or whatever mechanism is used to install the out-of-tree Bcachefs kernel module doesn't work with the new kernel.
And, to be honest, it doesn't matter whether or not you're "right" or "wrong" here. Maybe you're completely correct about absolutely everything and Linus, Greg, Ted, Miguel, Sasha, Josef, and everyone else involved are stupid and don't understand what it takes to develop reliable software. So what? They're your colleagues, some of them are your bosses. Everyone on Hacker News could take your side here and think you've been mistreated, it doesn't help. You'd still be thrown out of the kernel. You'd still be failing your users by not maintaining a good enough relationship with your colleagues and bosses to stay in-tree. You could be completely right on every technical matter and it does not matter.
If you play your cards right, you could maybe end up in a situation where you run the Bcachefs project entirely out-of-tree, with yourself as the supreme leader who doesn't bow down to the demands of anyone, with your own development and release process; and then someone else takes responsibility for pushing your code into the upstream kernel, following Linus's rules. They would dissect your releases and backport bug fixes while leaving out important features, in accordance with Linus's rules. Time will tell if you can find anyone to do that. And time will tell if you posess the humility necessary to let someone else ultimately control the experience most of your users will have.
He is not your boss. But he is the BDFL of the project you (and all of us) want bcachefs to be contributed to.
In an ideal scenario for you there would be more of a two way relationship with him meeting your demands, but he has all of the leverage in this situation. It doesn’t even matter how wrong he may be: He controls the kernel and that’s where file systems belong.
Linus is not your boss in the sense that he pays you and can tell you what you do day o day, but he is your "boss" in the sense that he's the one who ultimately approves your work (which includes both your code and your conduct).
It's a "two-way street" (you can walk away as much as he), but you need to understand that this is not an equal relationship. It might have been if Linux did not yet have a file system and you were the only person who could build one. If that was the case, Linus might have swallowed his pride for the good of the project. But as it stands, Linux has existed for some 35 years without Bcachefs and can continue to do so. So the key stakeholders have simply decided that with this amount of friction, despite the technical advantages, it's not worth the trouble (yes, it is sad).
Very realistically and bluntly, you have 3 options:
a) Learn to work Linus and other kernel maintainers in ways that are comparable with their work and processes. Remember, you're on their territory, and when in Rome, do as the Romans do.
b) Keep and develop Bcachefs out of kernel. That way you can stay on your own turf and work on your terms, but Bcachefs is going to be a much less attractive and viable option, leave alone become the default fs.
c) Have someone else do the integration work and collaboration with the kernel team.
These are your options, but a combination is also an option. I would probably recommend starting with option b first and finish the bulk of the work out of tree. Then once it's all done and ready to ship, try to get it into the kernel as politely and timely as possible (you shouldn't need any late commits this time). Continue developing new and experimental functionality out of tree to keep the number of PRs (and thus possible causes of friction) low. I don't know if at any point you'd want to ask someone else to interface with the kernel team. I think it's far preferable if you can learn to do it yourself. Knowing how to work with people (including difficult people) is an incredibly important and useful skill in almost anyone's career. Maybe find a communication/diplomacy mentor? I've never heard anyone complain about your engineering skills, but this is really holding you back.
Again and as always, thank you for your hard work. I wish you all the best and hope that some day we can all use Bcachefs by default.
No, it's not an equal relationship. Linus and the kernel do not have a great track record on filesystems :)
XFS has been burning through maintainers, and btrfs never fully stabilized. Given that, it doesn't make sense for anyone to be trying to dictate; that's a track record that should be cause for reexamining how we do things.
Working with the kernel has been extremely disruptive to bcachefs development and the community, so as with anyone else who's being disruptive and not listening, at some point I have to say "enough is enough, you're taking up too much of my time, we can work together again when you figure some things out".
I do not strictly need bcachefs to be in the kernel. I do need a functioning release process and a stable community free of drama.
> Working with the kernel has been extremely disruptive to bcachefs development and the community
From an excited and hopeful potential future user looking in, this sounds like "working with <insert only grocery store in town> has been extremely disruptive to me selling my produce", there's nowhere else your customers can realistically get your product, unless you want to only sell to extremely picky customers who will make the hour long trip out to your farm and back.
> I do not strictly need bcachefs to be in the kernel.
But I (and your other users) do...
I shouldn't be weighing in, I'm a lightweight with no skin in the game here, just a regular (very technical) user. I guess I just want you to know that your product has many people that want to use it, but even I won't drive to your farm for it, as I can't risk a Linux-update breaking the DKMS-modules that make my system able to use the bcachefs filesystem all my data is on.
I don't know what possible avenue we have of getting bcachefs back into the kernel and maintained, but I hope you find it, whatever it is.
I'm not trying to do this as fast as possible and get it out to every single user as fast as possible
That's tech industry thinking; that is what btrfs did :)
In the long run, slow is fast and wins the race. Being in the kernel would have been great if it grew the development community, but instead the opposite happened - it drove people way.
The important thing is to get it done, with all the reliability and hardening and features that people want. There's no reason it can't go back in later.
I mean I've read a lot of what you've posted everywhere, and I can't really say I disagree with much of it, it's just a shame it all happened the way it did.
Hope "go back in later" isn't too far down the line, I have 10x8TB spinners, and 4x2TB NVMe disks that I'm looking to move from md-raid + BTRFS to something else, and I really want that to be an in-tree filesystem.
Pointing the finger at the skills I lack and my inability, while ignoring the wider picture, of the kernel burning out maintainers and not doing well on filesystems.
It's wearying.