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.

▲

nylonstrung 3 days ago | parent | next [-]

I really want bcachefs to succeed.

Please just swallow your pride like all the other maintainers.

This is so self-defeating and it's disappointing the drama has overshadowed the project

▲

solarkraft 2 days ago | parent | prev | next [-]

> 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.

▲

mort96 3 days ago | parent | prev [-]

> 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.

▲

koverstreet 3 days ago | parent [-]

Linus isn't my boss, though.

Am I paid by him or the Linux foundation? No.

Has he ever contributed to bcachefs in any way, is he in any way responsible for making sure that it works properly? No.

The only sense in which he has authority is that he can decide whether or not to pull it into his tree, but that's a two way relationship.

▲

mort96 3 days ago | parent | next [-]

I have said my piece. It's not me you have to convince.

▲

solarkraft 2 days ago | parent | prev | next [-]

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.

▲

jjaksic 3 days ago | parent | prev [-]

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.

▲

koverstreet 2 days ago | parent [-]

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.

	▲	2 days ago \| parent [-]
		[deleted]