On Fri, Jun 20, 2025 at 04:25:58AM +0300, Jani Partanen wrote: > > On 20/06/2025 4.09, Kent Overstreet wrote: > > I'm not seeing that _you_ get that. > > > How hard it is? > > New feature window for 6.16 was 2 weeks ago. > > rc<insert number here> is purely for fixing bugs, not adding new features > and potential new bugs.
That's an easy rule for the rest of the kernel, where all your mistakes are erased at a reboot. Filesystems don't have that luxury. In the past, I've had to rush entire new on disk format features in response to issues I saw starting to arise - I think more than once, but the btree bitmap in the member info section was the big one that sticks in my mind; that one was very hectic, but 100% proved its worth. Thankfully, we're well past that. This time, we're just talking about a ~70 line patch that just picks overwrites instead of updates from the journal and sorts them in reverse order. So your next question might be - why not leave that in a branch for the users that need it until the next merge window? For a lot of users, compiling a kernel from some random git repository is a lot to ask. I spend a lot of time doing what amounts to support; that's just how it is these days. But rc kernels are packaged by most kernels, and we absolutely do not want to wait an additional 3 months for it to show up in a release kernel - For something that might be the difference between losing a filesystem and getting it back. There's also a couple patches for tracepoints and introspection improvements; I don't know if Linus was referring to those. But those are important too. I think at least as much about "how do I make this codebase easy to debug; how do I make it _practical_ to support and QA when it's running on random user machines in the wild" as I do about the debugging itself. That's at least as important as the debugging; making it maintainable. Partly that's about maintaining a quick feedback cycle between myself and the users reporting issues; that builds trust, brings people into the community, turns into opportunities to teach them more about testing and QA and bug reporting. I also never cease to be amazed how often I add some bit of logging or improve a tracepoint or some introspection - and then a week later I'm working on something else and it's exactly the thing I need. IOW - it's not just about fixing the bugs, it's about how we fix the bugs. Tools to repair, tools to debug, it's all just tools, all the way down...
