←back to thread

215 points ksec | 3 comments | | HN request time: 0s | source
Show context
Volundr ◴[] No.45076237[source]
Damn. I was enjoying not having to deal with the fun of ZFS and DKMS, but it seems like now bcachefs will be in the same boat, either dealing with DKMS and occasional breakage or sticking with the kernel version that slowly gets more and more out of date.
replies(4): >>45076451 #>>45076664 #>>45076776 #>>45076818 #
WD-42 ◴[] No.45076818[source]
The article says that bcachefs is not being removed from the mainline kernel. This looks like mostly a workaround for Linus and other kernel devs to not have to deal with Kent directly.
replies(2): >>45077114 #>>45077151 #
tux3 ◴[] No.45077151[source]
It's complicated, no one really knows what "externally maintained" entails at the moment. Linus is not exactly poised to pull directly from Kent, and there is no solution lined-up at the moment.

Both Linus and Kent drive a hard bargain, and it's not as simple as finding someone else to blindly forward bcachefs patches. At the first sign of conflict, the poor person in the middle would have no power, no way to make anyone back down, and we'd be back to square one.

It's in limbo, and there is still time, but if left to bitrot it will be removed eventually.

replies(1): >>45077281 #
immibis ◴[] No.45077281[source]
That person would be accountable to Linus, but not to Kent.
replies(1): >>45077372 #
tux3 ◴[] No.45077372[source]
Unfortunately, there's also nothing they can do if Kent says no. Say there's a disagreement on a patch that touches something outside fs/bcachefs, that person can't exactly write their own patches incorporating the feedback. They're not going to fork and maintain their own patches. They'd be stuck between a rock and a hard place, and that gets us back to a deadlock.

The issue is that I have never seen Kent back down a single time. Kent will explain in details why the rules are bullshit and don't apply in this particular case, every single time, without any room for compromise.

If the only problem was when to send patches, that would be one thing. But disagreements over patches aren't just a timing problem that can be routed around.

replies(1): >>45078945 #
koverstreet ◴[] No.45078945[source]
The key thing here is I've never challenged Linus's authority on patches outside fs/bcachefs/; I've quietly respun pull requests for that, on more than one occasion.

The point of contention here was a patch within fs/bcachefs/, which was repair code to make sure users didn't lose data.

If we can't have clear boundaries and delineations of responsibility, there really is no future for bcachefs in the kernel; my core mission is a rock solid commitment to reliability and robustness, including being responsive to issues users hit, and we've seen repeatedly that the kernel process does not share those priorities.

replies(2): >>45079197 #>>45082574 #
tuna74 ◴[] No.45082574[source]
Linus T is responsible for everything in Linux, it is his project and he is the maintainer. He can do everything he wants in his branch and people just have to accept it. If you want to be responsible you have to fork Linux.
replies(1): >>45083395 #
koverstreet ◴[] No.45083395[source]
Let's examine this, shall we?

Has he ever even been involved with a bcachefs bug? No, aside from arguing against shipping bugfixes.

Has he contributed in any way, besides merging code? No...

Has he set rules or guidelines that benefited bcachefs reliability? No, but he has shouted down talk about automated testing.

I think you're confusing power with responsibility.

replies(1): >>45086320 #
1. immibis ◴[] No.45086320[source]
You're still doing that thing where you assume everyone else is you. Linus's job (some of which he delegates) is to take the contributions from ALL the hundreds of maintainers, and bundle it into a unified coherent whole. He is not only responsible for bcachefs reliability. In the train analogy I already used, he is the train driver, he is responsible for getting everyone who is on the train to their destination, but he is not responsible for ensuring that you're on the train. It's your responsibility to ensure that you're on the train when it departs.

You are one of those maintainers (not any more). Your code can be taken into the bundle (not any more), but on the bundle's schedule, not yours. You have consistently failed to understand that the train doesn't wait for you - if you are late, you get on the next one. If you don't want to get on the next one, then don't be late. Normal people, after missing a train once or twice, would adjust their schedule accordingly so they won't miss it next time. But your exclusive, repeated reaction has been to yell at the train driver and the station master, which is why you've been kicked out of the station.

Have you ever ridden a train, by the way? Were you on time? (Deutsche Bahn doesn't count because they're not on time)

replies(1): >>45086488 #
2. koverstreet ◴[] No.45086488[source]
We're not talking about situations where the bcachefs changes could plausibly affect the rest of the kernel, and I am well known even within the kernel community for being on top of potential issues and responsive on bugs.
replies(1): >>45088920 #
3. immibis ◴[] No.45088920[source]
The merge window policy is not limited to cases where the new bcachefs features affect the rest of the kernel.