Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

[GrimR3]

Michael l actually the drama isn't on lkml but on fsdevel https://lore.kernel.org/linux-fsdeve...ernel.org/T/#t

some choice quotes from kent:

Thanks for the link. Seems like the thread has cooled and now they have a tentative agreement to not push things on Saturday.

[cb88]

You must be new here. If you screw up or make life difficult for others, Linus is absolutely going to read you the riot act. Always has, always will.

Nothing he did does that though.

[cb88]

He can't stop it. He will continue throwing mud on others, believing he's the only one who is right and he has to save the world

It's not mud if its true. Most of the stuff coming out of big companies is design by committee crap anyway...

[Errinwright]

Yes, please re-read
https://lore.kernel.org/[email protected]/

Daily double-facepalm limit was expended on this reply.

[LockedPotato]

Literally read the article. Even Linus knows it had testing, just not outside his tree.

So you're saying he pushed code that wasn't tested on main to main. Glad we agree. You're probably as infantile as Kent.

[Daktyl198]

well kent participated in linux for decades and only recently there seems to be that much drama. so something did change.

Most of Kent's contributions pre-bcachefs were individual patches on existing subsystems, that went through others before they hit Linus. Bcachefs was developed out of tree for years and really struggled to even get merged into the mainline kernel because of Kent's development issues and failure to listen to what he was told. He basically got it in on his very last chance because he'd already submitted it like 4 times and all 4 times he had to be told the same shit about how to modify it to be mainlined.

Hence Linus's "I hoped that by bringing you into the kernel things would change". But they haven't, Kent develops in his own way. I don't begrudge him, his filesystem, or his way of development... but if he doesn't play by kernel rules, his software should be developed entirely out-of-tree and brought in by interested distros.

(I'd really rather just the kernel development system be entirely reworked and brought up to modern standsards, but alas. That's not gonna happen).

[PuckPoltergeist]

Most of Kent's contributions pre-bcachefs were individual patches on existing subsystems, that went through others before they hit Linus.

He developed and is maintainer of bcache (included in linux since 2013!)

[Mathias]

So you're saying he pushed code that wasn't tested on main to main. Glad we agree. You're probably as infantile as Kent.

Let's look up your original comment:

If he keeps pushing patches with zero testing it's almost certainly going to eat your data.

I have no direct affiliation with Kent or other Linux devs. But from what I read, Kent does extensive testing on every commit he pushes that actually test the FS in ways meant to break the FS to show that it doesn't break. AFAIK he does extensive testing that Bcacefs doesn't eat your data.

What he didn't do send the patches to others to test them. That's what Linus complained about, and for good reason. What he didn't test is BE systems, because they are hard to come by. BE didn't compile and that is what Linus is mostly concerned about. Sure it's Kents fault for not sending the patches earlier and I don't defend him for his behaviour. Sure if you're on BE, Bcachefs is pretty much untested and it might eat your data and kill a kitten in the process. I don't defend Kent for his behaviour towards the LKML.

But saying "patches with zero testing" is something even Linus didn't say. And when you were called out for it, you posted quotes that didn't support your claim.

[lumks]

Boy oh boy. Is it just me or does Kent sound like an LLM/"AI"? Overexplaining things with nonsense examples, hallucinating the importance of his project and his testing ground, playing down other projects.

Kick this crap out of the tree, Linus.

[PuckPoltergeist]

Neither Kent nor I implied that that other devs don't care.

Just read his reply to Josef, where he says this directly.

I have said: they didn't sufficiently commit to robustness and data integrity. Commitment is when you say: "This filesystem has a design goal of paramount data integrity".

Other filesystems simply do not claim that they are designed with such properties, mostly because such high standards were not part of the original design.

I'm sure you know that's not true. Btrfs was designed with data integrity in mind. That's why csums and redundancy was considered from the beginning. XFS is adding those features because of this. The difference is, these developers aren't that loud as Kent.

Everyone has a right to state their opinion, and to point out possible design defects in other projects.
That includes Kent.
Requiring or expecting just flattery is dangerous. Criticism should be appreciated, critics should not be kicked out. Criticisms should be seriously considered, not brushed aside.
Of course, many times critics are in the wrong, but that is also OK. You can't expect every criticism to always be true.
When criticism is suppressed (whether intentionally or not), then you get into big trouble.

Another problem is that many people react negatively to criticism. I think those people should learn to be more tolerant of critics.

Why wouldn't Kent be allowed to say "I think that I designed this better than this other thing is designed, and that was my goal". He has all the right to hold such opinions (otherwise he would have no reason to ever start working on BcacheFS).

It's not about criticism, it's about accusing and offending. Kent is not saying "I think that I designed this better than this other thing is designed, and that was my goal", he is saying "You don't have done it right" and "It's your fault, that I can't write better code".

https://lore.kernel.org/linux-fsdevel/ivjo62ghagmcoacjdtoute7mzwkcj3gu6hgdygjry5x7uiqgid@6axrxbn5auvy/

https://lore.kernel.org/linux-fsdevel/nlwn4yodlo54hdbyil3kyxhaqgg5dmmdfvizsyj77oczgzezt2@m3qbtep3fhln/

https://lore.kernel.org/all/[email protected]/T/#m031d906c66099ba8f341e7622a282c7c3302e4ff