Message-ID: <774936dd-32b8-46f1-a849-2f8ea76a24ac@gmail.com>
Date: Fri, 27 Jun 2025 12:16:09 -0700
From: Kyle Sanderson <kyle.leet@...il.com>
To: linux-kernel@...r.kernel.org
Cc: linux-bcachefs@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 Kent Overstreet <kent.overstreet@...ux.dev>,
 Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [GIT PULL] bcachefs fixes for 6.16-rc4

On 6/27/2025 12:07 PM, Kyle Sanderson wrote:
> On 6/26/2025 8:21 PM, Linus Torvalds wrote:
>> On Thu, 26 Jun 2025 at 19:23, Kent Overstreet 
>> <kent.overstreet@...ux.dev> wrote:
>>>
>>> per the maintainer thread discussion and precedent in xfs and btrfs
>>> for repair code in RCs, journal_rewind is again included
>>
>> I have pulled this, but also as per that discussion, I think we'll be
>> parting ways in the 6.17 merge window.
>>
>> You made it very clear that I can't even question any bug-fixes and I
>> should just pull anything and everything.
>>
>> Honestly, at that point, I don't really feel comfortable being
>> involved at all, and the only thing we both seemed to really
>> fundamentally agree on in that discussion was "we're done".
>>
>>                Linus
> 
> Linus,
> 
> The pushback on rewind makes sense, it wasn’t fully integrated and was 
> fsck code written to fix the problems with the retail 6.15 release - 
> this looks like it slipped through Kents CI and there were indeed 
> multiple people hit by it (myself included).
> 
> Quoting someone back to themselves is not cool, however I believe it 
> highlights what has gone on here which is why I am breaking my own rule:
> 
> "One of the things I liked about the Rust side of the kernel was that 
> there was one maintainer who was clearly much younger than most of the 
> maintainers and that was the Rust maintainer.
> 
> We can clearly see that certain areas in the kernel bring in more young 
> people.
> 
> At the Maintainer Summit, we had this clear division between the 
> filesystem people, who were very careful and very staid, and cared 
> deeply about their code being 100% correct - because if you have a bug 
> in a filesystem, the data on your disk may be gone - so these people 
> take themselves and their code very seriously.
> 
> And then you have the driver people who are a bit more 'okay', 
> especially the GPU folks, 'where anything goes'.
> You notice that on the driver side it’s much easier to find young 
> people, and that is traditionally how we’ve grown a lot of maintainers.
> " (1)
> 
> Kent is moving like the older days of rapid development - fast and 
> driven - and this style clashes with the mature stable filesystem 
> culture that demands extreme caution today. Almost every single patch 
> has been in response to reported issues, the primary issue here is 
> that’s on IRC where his younger users are (not so young, anymore - it is 
> not tiktok), and not on lkml. The pace of development has kept up, and 
> the "new feature" part of it like changing out the entire hash table in 
> rc6 seems to have stopped. This is still experimental, and he's moving 
> that way now with care and continuing to improve his testing coverage 
> with each bug.
> 
> Kent has deep technical experience here, much earlier in the 
> interview(1) regarding the 6.7 merge window this filesystem has been in 
> the works for a decade. Maintainership means adapting to kernel process 
> as much as code quality, that may be closer to the issue here.
> 
> If direct pulls aren’t working, maybe a co-maintainer or routing changes 
> through a senior fs maintainer can help. If you're open to it, maybe 
> that is even you.
> 
> Dropping bcachefs now would be a monumental step backward from the 
> filesystems we have today. Enterprises simply do not use them for true 
> storage at scale which is why vendors have largely taken over this 
> space. The question is how to balance rigor with supporting new 
> maintainers in the ecosystem. Everything Kent has written around 
> supporting users is true, and publicly visible, if only to the 260 users 
> on irc, and however many more are on matrix. There are plenty more that 
> are offline, and while this is experimental there are a number of public 
> sector agencies testing this now (I have seen reference to a number of 
> emergency service providers, which isn’t great, but for whatever reason 
> they are doing that).
> 
> (1) https://youtu.be/OvuEYtkOH88?t=1044
> 
> Kyle.

Re-sending as this thread seems to have typo'd lkml (removing the bad 
entry).

Kyle.

Powered by blists - more mailing lists