Linus' message is a bit vague, and could be interpreted as Linus wants to find someone else that Kent can report to as an intermediary, one which will stop any features from getting into the kernel during RC window.
That said, I really don't understand why Kent decides to take a stand on the hills he does. In this case he already helped one user out-of-tree, so presumably they compiled a custom kernel. Sure it's a bit more work to help others with the same if they also have that issue, but not insurmountable. Alternatively users could just wait a few weeks or restore from backup. It's an experimental file system after all.
Instead he decides this is the hill he wants to die on. After just getting back from a timeout for doing exactly the same thing...
> I really don't understand why Kent decides to take a stand on the hills he does
Yes, it confuses me as well. I appreciate Kent has some different opinions and that's okay, but it's not that hard to comply with the Linux dev process? And while one can reasonably disagree with some aspects of that, it's not like the process is unreasonable. And it's not like Linus is that inflexible either – if it makes sense to break a rule then that's always an option.
The context is [1]. Some of these commits probably sound reasonable to pull (e.g. the regression fixes). But an entire new feature? wat? After all the previous discussions about this type of thing, I cannot phantom why Kent thought this would pass without conflict.
bcachefs being pulled was one of my predictions for 2025 by the way.[2] I hoped I was wrong, but it's not a shock to anyone who has followed how things have been going.
Linus' message is a bit vague, and could be interpreted as Linus wants to find someone else that Kent can report to as an intermediary, one which will stop any features from getting into the kernel during RC window.
That said, I really don't understand why Kent decides to take a stand on the hills he does. In this case he already helped one user out-of-tree, so presumably they compiled a custom kernel. Sure it's a bit more work to help others with the same if they also have that issue, but not insurmountable. Alternatively users could just wait a few weeks or restore from backup. It's an experimental file system after all.
Instead he decides this is the hill he wants to die on. After just getting back from a timeout for doing exactly the same thing...
> I really don't understand why Kent decides to take a stand on the hills he does
Yes, it confuses me as well. I appreciate Kent has some different opinions and that's okay, but it's not that hard to comply with the Linux dev process? And while one can reasonably disagree with some aspects of that, it's not like the process is unreasonable. And it's not like Linus is that inflexible either – if it makes sense to break a rule then that's always an option.
The context is [1]. Some of these commits probably sound reasonable to pull (e.g. the regression fixes). But an entire new feature? wat? After all the previous discussions about this type of thing, I cannot phantom why Kent thought this would pass without conflict.
bcachefs being pulled was one of my predictions for 2025 by the way.[2] I hoped I was wrong, but it's not a shock to anyone who has followed how things have been going.
[1]: https://lwn.net/ml/all/4xkggoquxqprvphz2hwnir7nnuygeybf2xzpr...
[2]: https://news.ycombinator.com/item?id=42810672