Re: [GIT PULL] bcachefs changes for 6.17

Gerald B. Cox
2025-08-10T04:26:28Z

Please excuse, sending this again because I forgot to put in plain text mode.

Been watching this thread unfold. There are valid concerns, sure—but
I’d caution folks against mistaking frustration for hostility.

Kent’s been carrying a heavy load with bcachefs, and it shows. Solo
stewardship at this scale isn’t just technical—it’s psychological.
When someone’s under pressure and feels attacked, responses get sharp.
That’s not ideal, but it’s not malicious either.

If we’re serious about maintaining a healthy kernel community, we need
to be better at recognizing when someone’s burning out—and not make it
worse. The CoC isn’t just there to call out bad behavior; it’s
supposed to guide us toward empathy and restraint.

Kent, if you’re reading this: it’s clear you’re reacting to what feels
like a pile-on. That’s understandable. But at this point, stepping
back might serve you better than continuing to reply. Let the code
speak. Let others weigh in. You’ve done the hard part—now give it
room.

And really, this whole thread feels beneath what the kernel community
should be. If there’s a serious question about bcachefs’s future, it
ought to be a quiet, direct conversation between Kent and Linus—not a
public spectacle. We’ve seen how these things go, and it rarely ends
well unless someone redirects the tone.

On Sat, Aug 9, 2025 at 9:13 PM Kent Overstreet
<kent.overstreet@linux.dev> wrote:
>
> On Sun, Aug 10, 2025 at 12:05:28AM -0400, Sasha Levin wrote:
> > On Sat, Aug 09, 2025 at 11:17:44PM -0400, Kent Overstreet wrote:
> > > On Sat, Aug 09, 2025 at 10:24:36PM -0400, Theodore Ts'o wrote:
> > > > And how did you respond? By criticizing another file system, and
> > > > talking about how wonderful you believe bcachefs to be, all of which
> > > > is beside the point. In fact, you once again demonstrated exactly why
> > > > a very large number of kernel deevlopers have decided you are
> > > > extremely toxic, and have been clamoring that your code be ejected
> > > > from the kernel. Not because of the code, but because your behavior.
> > >
> > > I would dearly love to have not opened that up, but "let's now delete
> > > bcachefs from the kernel" opened up that discussion, because our first
> > > priority has to be doing right by users - and a decision like that
> > > should absolutely be discussed publicly, well in advance, with all
> > > technical arguments put forth.
> >
> > Kent,
> >
> > You say our first priority has to be doing right by users, and I agree -
> > but doing right by users means maintaining a healthy, functioning
> > development community. A toxic community that drives away contributors
> > fails its users far more severely than the absence of any single
> > filesystem ever could.
> >
> > Look at this thread again. Really look at it. Neither Ted nor Josef
> > raised a single technical argument against bcachefs. They didn't
> > criticize your code, your design decisions, or your engineering. Josef
> > explicitly praised your technical work. Ted has repeatedly shown respect
> > for your code. The discussions about potentially dropping bcachefs
> > aren't happening because it's technically inferior to ext4, xfs, or
> > btrfs. They're happening because your personal interactions are
> > undermining the health of the community that maintains all of these
> > filesystems.
> >
> > > "Work as service to others" is something I think worth thinking about.
> > > We're not supposed to be in this for ourselves; I don't write code to
> > > stroke my own ego, I do it to be useful.
> >
> > Service to others includes maintaining professional relationships with
> > your colleagues. It includes building rather than tearing down. It
> > includes recognizing that a healthy community serves users better in the
> > long run than any individual contribution, no matter how technically
> > excellent.
> >
> > The kernel has thrived for over 30 years not just because of technical
> > excellence, but because it has (mostly) maintained a collaborative
> > environment where developers can work together despite disagreements.
> > That collaborative environment IS doing right by users.
> >
> > No filesystem is worth destroying that.
>
> Then can we please drop all this madness?
>
> I do hereby solomnly swear that I will refrain from critizing btrfs ever
> again, or any other code anywhere in the kernel (if that is the wish) -
> as long as Linus stops trying to dictate on patches internal to
> fs/bcachefs/.
>
> If it affects the rest of the kernel, that's fair game; I just want to
> be able to get work done.
>