Re: [GIT PULL] bcachefs fixes for 6.16-rc4

["John Stoffel" <john@stoffel.org>]

>>>>> "Kent" == Kent Overstreet <kent.overstreet@linux.dev> writes:

I wasn't sure if I wanted to chime in here, or even if it would be
worth it.  But whatever.

> On Thu, Jun 26, 2025 at 08:21:23PM -0700, Linus Torvalds wrote:
>> On Thu, 26 Jun 2025 at 19:23, Kent Overstreet <kent.overstreet@linux.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.

> Linus, I'm not trying to say you can't have any say in bcachefs. Not at
> all.

> I positively enjoy working with you - when you're not being a dick,
> but you can be genuinely impossible sometimes. A lot of times...

Kent, you can be a dick too.  Prime example, the lines above.  And
how you've treated me and others who gave feedback on bcachefs in the
past.  I'm not a programmer, I'm in IT and follow this because it's
interesting, and I've been doing data management all my career.  So
new filesystems are interesting.  

But I've also been bitten by data loss, so I'd never ever trust my
production data to something labeled "experimental".  It's wonderful
that you have stepped up and managed to get back people's data when
bugs in the code have caused them to lose data.  

But for god's sake, just because you can find and fix this type of bug
during the -rc series, doesn't mean you need to try and patch it NOW.
Queue it up for the next release.  Tell people how they can pull the
patch early if they want, but don't push it late in the release
cycle.  

I've been watching this list since the early 2.x days, and I've seen
how the workflow has evolved over time.  I've watched people burn out
and leave, flame wars and all kinds of crap.  And the people who have
stayed around are generally the nice people.  The flexible people.
The people who know when to back the f*ck off and take their time.  

> When bcachefs was getting merged, I got comments from another
> filesystem maintainer that were pretty much "great! we finally have
> a filesystem maintainer who can stand up to Linus!".

Is that in terms of being dicks, or in terms of technical ability?  Or
in terms of being super productive and focussed and able to get work
done.  Standing up doesn't mean you're right.  Or wrong.  

> And having been on the receiving end of a lot of venting from them
> about what was going on... And more that I won't get into...

> I don't want to be in that position.

So don't!  Just step back a second.  Go back and read and re-read all
the comments Linus had made about the workflow and release process
over the years, much less decades of the kernel development.  I'm not
sure you realize how much work it is to have people blasting patches
at you all day long, 365 days a year, and who think their patches are
the most important thing in the entire world bar none.   

Just reflect on this for a second.  Take your hands off your keyboard,
and don't type anything.  And think about how many other people also
think their patches are the most important.  

And about the users who _need_ _that_ _patch_ _right_ _now_ to fix a
problem.  Why doesn't Linus see that I'm important and my part of the
kernel is the most important!  

Just let that sink in a bit.  

Then think about how many people do not care about bcachefs at all,
who don't even know it exists.  And haven't used it or want to use
it.  Are they less important?  What about the graphics driver they
need to get _their_ work done right now?  Is that more or less
important?

> I'm just not going to have any sense of humour where user data integrity
> is concerned or making sure users have the bugfixes they need.

So release your own patches in your own tree!  No one is stopping you!
Have your '6.17-next' branch with the big re-working to fix this
horrible issue.  But send in just the minimal patch _now_.  The
absolutely the smallest patch.  

Or just send in a revert for all you have done in the current series
which is breaking people, because it wasn't quite baked enough for
stability.  Fall back, re-group, re-submit it all on the next release.

Slow down.  

> Like I said - all I've been wanting is for you to tone it down and stop
> holding pull requests over my head as THE place to have that discussion. 

And you need to stop thinking you are the most important thing and
only you can decide when bcachefs needs to be updated or not in the
kernel tree.  

> You have genuinely good ideas, and you're bloody sharp. It is FUN
> getting shit done with you when we're not battling.

I'm honestly amazed at your abilities here Kent, even though you can
be an abrassive person too.  

> But you have to understand the constraints people are under. Not
> just myself.

Dude, you need to listed to Linus saying this exact same line back to
you.

John