[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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