Like the sibling commenter, I suspect the word “experimental” is being used here to try and evade the rules that, somehow, every other part of the kernel manages to do just fine with.
I have no context on the situation or understanding of what the right set of rules here is, but the difference between filesystems and other code is that bugs in the filesystem can cause silent, persistent corruption for user data, on top of all the other failure modes. Most other parts of the kernel don't have such a large persistence capability in case of failure. So I can understand if filesystems feel the need to be special.
I will also say that bcachefs's selling point - and probably a major reason people are so excited for it - is amount of effort it puts into avoiding data corruption. Which tells you something about the perceived quality of other filesystems on Linux. Which means that saying "other filesystems seem fine with the rules" misses the very fact that people have seen too much data corruption with other filesystems and want something that prioritizes it higher.
It's a bad sign when the key founders leave like that, filesystems require a lot of coherence of design and institutional knowledge to be retained.
The problem are new features, general improvements, and fixes that are actually features or require nontrivial refactorings. I understand the temptation, but these carry significantly higher risks than a well-thought out bugfix and are thus not welcome outside the merge window. Most prior rows between Kent and Linus have been about such patches, sometimes surreptitiously mixed in with more benign fixes.
This time his argument is "think of the distro users", but this won't fly - those either accept that using an experimental FS has consequences, or Kent learns how to work with the kernel community instead of testing the boundaries of the rules in the name of all the oppressed kernel developers gatekept by Linus. Shipping bugfixes for bugfixes would be kinda embarrassing for everyone involved (Kent, Linus, and the distros!), and that's why Linus rejects his PRs.
We're very far along in that process now, but it's still marked as experimental because it is not quite ready for widespread deployment by just anyone. 6.16 is getting damn close, though.
That means a lot of our users now are people getting it from distro kernels, who often have never compiled a kernel before - nevertheless, they can and do report bugs.
And no matter where you are in the rollout, when you get bug reports you have to fix them and get the fixes out to users in a timely manner so that they can keep running, keep testing and reporting bugs.
It's a big loss if a user has to wait 3 months for a bugfix - they'll get frustrated and leave, and a big part of what I do is building a community that knows how the system works, how to help debug, and how to report those bugs.
A very common refrain I get is "it's experimental <expletive deleted>, why does it matter?" - and, well, the answer is getting fixes out in a timely manner matters just as much if not more if we want to get this thing done in a timely manner.
At the time it looked like that could happen - there was real interest from Redhat prior to merging. Sadly Redhat's involvement never translated into much code, and while upstreaming did get me a large influx of users - many of which have helped enormously with the QA and stabilization effort - the drama and controversies have kept developers away, so on the whole it's meant more work, pressure and stress for me.
So DKMS wouldn't be the worst route, at this point. It would be a real shame though, this close to taking the experimental label off, and an enormous hassle for users and distributions.
But it's not my call to make, of course. I just write code...
well there you have it. i am not saying the drama is your fault because it really doesn't matter whose fault it is. regardless of who is causing drama, your only chance to reduce drama (and stress for you) is to deescalate. even if linus is causing the drama, actually especially if linus is causing the drama (we all know that he doesn't have the most agreeable personality) you need to do things his way and work to earn his trust.
others here in the comments ask you to recognize and admit you are wrong, but i'd say no, you don't have to. this is not a matter of who is right. that's completely besides the point. it's a matter of politics and diplomacy. agree to disagree and move on. that is what i hope you can recognize. to accept defeat of an argument even if you are right, and to avoid causing arguments in the first place. it's like marriage. if you want to keep the relationship, you need to defer until you earn their trust. but unlike marriage you can't ask others to join you in relationship counseling. you have to do all the relationship work yourself.
i am rooting for you, and i look forward to the day that i can use bcachefs myself.
btw: is there any goal to support in place conversion from ext4 like btrfs supports. (and maybe even from btrfs :-)
In place conversion from btrfs needs an FIEMAP extension, but ext4 and xfs are supported
That said, I vaguely seem to recall that bcachefs ended up involving changes to other parts of the kernel to better support it; if that's true then DKMS is likely to be much more painful if not outright impossible. It's fine to compile one module (or even several) against a normal kernel, but the moment you have to patch parts of the "main" kernel it's gonna get messy.
It seems like you want that kind of fast turn around time in the kernel though, which strikes me as an impossible goal.
The Kernel's pace is predictable, even billion $ corporates can live with it, and it's not like Linus hasn't accommodated you in the past. But continuing to do so will make people stop believing you are acting in good faith, and the outcome of that will be predictable.
This is simply how the development model is like in the Linux kernel. Exceptions happen, but they sometimes backfire and highlight why the rules matter in the first place, and therefore they are unlikely to change.
Either the bugfix is not serious and they can wait because the system is mature. Or, The fs is so unstable you shouldn't be pandering to the crowd that struggle with build deps and make install.
There is no in between, this is the situation. And the "but not all bugs are equal" argument doesn't stand.
I know if I read of a metadata but getting fixed in ext4 or ZFS there's a very small chance of this causing my platter to evaporate. By definition of stable, if that was happening it would be hitting that one unfortunate guy (<0.001% of users) running a weird OS or hardware and that's just the luck of the draw.
If the fix is from a fs marked experimental, yes I kinda expect this could fry my data and hurt kittens. That's what experimental and stable mean. That means I expect up to 100% of users to be impacted under certain workflows or scenarios.
Everything outside of this is wasted energy and arguing with the tide.
Is the wait really 3 monts away? I don't exactly know the release cycle, but for me kernels are released quite frequently, at least there are RC sooner than 3 months. Just checked latest history and major releases are 2 months apart - and between them there are minor ones.
People using experimental features are quite aware how to get new experimental kernel sources.
This is incredibly short-sighted. You're talking about 1 user 3 months, and you think that's "big" ? I'd say it's a much bigger loss if the project gets kicked out because of one person's impatience. Then everybody will have to wait forever, how is that better?
If the fs is as good as you claim, then you better play by the rules and make sure the project survives and eventually goes GA. If it happens a few months later, then so be it. Think about the long term.
If you're worried about a single user leaving, then a much better strategy would be to explain to this user the Linux release timeline, or how to apply a patch, than to go up toe to toe against Linus.
And btw, squeezing a fix/feature in at the last minute in order to help one user is not as good as you think it is. Even if that one user appreciates your responsiveness, to everyone else it sends a message that the key dev is super impatient and unprofessional. So even if you manage to keep that one user, how many potential users are you losing by sending that message?