The astounding ignorance of some people...
Failure to even understand, let alone practice, any form of release engineering hygene IS a failure of technical merit.
> "Work as service to others" is something I think worth thinking about. We're not supposed to be in this for ourselves; I don't write code to stroke my own ego, I do it to be useful. I honestly can't even remember the last time I wrote code purely for enjoyment, or worked on a project because it was what I wanted to work on. My life consists of writing code base on what's needed; to fix a bug, to incorporate a good idea someone else had, to smooth something over to make someone else's life easier down the line. Very rarely does it come from my own vision. My feelings are entirely secondary to the work I do.
Where do you get this idea? Lots of Linux users want lots of things - a big part of the reason Linux is so successful is because they don't get what they want, and the project instead focuses on stable development and release cycles. Many users want Linux to break userspace in this or that case. Do you think Linus should do that, because it's what the users want?
And lets not forget we're talking about an experimental filesystem. If you decide to use one of those, it's not asking too much of you to compile your own kernel.
Things always degenerate when it turns into power struggles and people are going "No, I decide!".
"Make sure thinks work" is the underlying principle, and it's based on that that the code should have been, and was merged.
But then the personality conflicts and power struggles came out, and there's no need for that.
- You don't go overriding a subsystem maintainer without a clear justification; if the patch in question has a good reason for being there and can't affect the rest of the kernel, there's a really high bar to clear. This has been an issue for the XFS folks in the past.
- We have to be able to have technical and policy discussions without it degenerating into "I don't trust you and you need therapy". That's just childish. The private discussions got really ugly on this one.
And, regarding bcachefs still being marked as experimental: I'm being much more conservative with the experimental label than btrfs or ext4 were. Your data is safer on bcachefs than btrfs, today: you're not going to lose a filesystem, repair is thorough and robust and complete.
You may still hit hiccups, which is why the experimental label is there, but robust and complete repair and rock solid multi device have been reason enough for a lot of people to switch already.
> You may still hit hiccups, which is why the experimental label is there, but robust and complete repair and rock solid multi device have been reason enough for a lot of people to switch already.
It doesn't matter how conservative you are being, it's _still_ marked as experimental. That simply means there's no great pressing need to get a new feature into the next possible release - users can either compile their own kernels, or wait if they aren't able to. They decided to use an experimental file system.
You're making life much harder for these users by causing bcachefs to be thrown out of the kernel. No matter how you twist and turn it, you're responsible for "breaking userspace" in this case. I have no interest in trying to convince you - I've seen people much better at explaining things than I can try to do so, and I've seen you ignore each and every one of them.
In any case as a Linux user, I want to thank you for your work and for your code which taught me a lot.
I hope it didn’t take too much of a toll on you.
Let’s hope that with the recent stabilization, the maintenance will be easier.
This is not a case of 2 equal entities failing to find a compromise.
One is both technically more valid and has the simple right to set the terms and processes regardless of other opinions, the other is neither. All failure to function is on Kent, not on any "struggle".
