> Too solve a bug with the filesystem that people in the wild were hitting.
So you acknowledge that this last episode involved trying to push new features into a RC.
As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions.
All these red flags were repeatedly raised in the mailing list by multiple kernel maintainers. Somehow you're ignoring all the feedback and warnings and complains raised by people from Linux kernel maintainers, and instead you've opted to try to gaslight the thread.
bcachefs has a ton of QA, both automated testing and a lot of testers that run my latest and I work with on a daily basis. The patch was well tested; it was for codepaths that we have good regression tests for, it was algorithmically simple, and it worked perfectly to recover a filesystem from the original bug report, and it performed flawlessly again not long after.
I've explained my testing and QA on the lists multiple times.
You, like the other kernel maintainers in that thread, are making wild assertions despite having no involvement with the project.
I repeat: it sounds an awful lot like you are trying to gaslight this thread. Not cool.
When this fact was again explicitly pointed out to you by Linus himself, you even tried to bullshit Linus and try to move the goalpost with absurd claims about how somehow it was ok to force untested and unreviewed features into a RC because somehow you know better about what users want or need as if it was some kind of justification for you to skip testing and proper release processes.
You need to set aside some time for introspection because you sound like you are your own worst enemy. And those you interact with seem to be fed up and had enough of these stunts.
Holy cow. You really deserved the kick. Fixes the RC in question aren't for bugfixes in general, but bugfixes for existing patches that in that RC.
It doesn't matter if you have bugs in the code still. At all. Having bugs in the code is not relevant. You are 100%, completely, inexcusably wrong if you were providing a bugfix that wasn't fixing something specifically changed in the RC.
Untested and unreviewed? Your own testing process and review process does not meet that. "Since then" is entirely irrelevant. Saying "I've proven it works" means you have no concept of stability in a release process.
I sincerely hope your code gets the boot from the kernel, because you clearly will never be able to maintain it there. You just don't listen. To anyone.
Your personal definitions of the above terms are irrelevant. How you think the kernel should be maintained, is meaningless. Whether you think your code is ready is an insane way to validate that you're "super special and get to have your way".
So you acknowledge that this last episode involved trying to push new features into a RC.
As it was made abundantly clear, not only is the point of RC branches to only get tiny bugfixes after testing, the feature work that was presented was also untested and risked introducing major regressions.
All these red flags were repeatedly raised in the mailing list by multiple kernel maintainers. Somehow you're ignoring all the feedback and warnings and complains raised by people from Linux kernel maintainers, and instead you've opted to try to gaslight the thread.