Linus Torvalds Isn't Happy With Some Of The Bcachefs Code For Linux 6.9

[Quackdoc]

This is like the 3rd article in the last month I've seen about Kent having poor interactions with other kernel maintainers/developers due to his weird ways of developing his corner of the kernel. I never even heard of the guy until this, and I've seen nothing positive about any of the work he's done tbh.

this article only implies a poor interaction if one seeks to look into kent as a bad person. Read the mailing list.

[johnandmegh]

Maintainer burnout comes from sheer volume of work and stress of making mistakes, not from Linus. Ask literally any maintainer.

Linus used to be worse with his words, but the reality is that he just doesn't soften the blow. If your code is awful to look at, let alone run, he will let you know. It's far better than somebody pussyfooting around and not really telling you what's wrong so you never know what needs fixing. Linus will call the code disgusting, then tell you exactly which part of it is bad and why so that you can fix it.

I agree that this attitude isn't the sole, or even primary cause of burnout - just that it doesn't help.

You're well within your right to disagree, of course, but IMO...

Pussyfooting around: "Your code has a lot of good things about it, great job! What would make it even better, is if - and I'm not saying you have to do it this way, please don't think of this as a critique - you looked at possibly optimizing the naming of your functions so that they flow a bit more consistently with other similar functions and enable more effective review..."

Direct, un-softened blows: "I couldn't read your code because the names don't follow established kernel logic. Rejected until that is fixed."

Needless drama: "Your idiotic code is so hard to read I could never even begin to include it, your function names are moronic, if you make it less disgusting then I can even look at the rest without puking"

I think only the first two are "professional", and only the last two are "helpful"...so I don't see anything wrong with shooting for the intersection of professional *and* helpful.

[Sonadow]

I agree that this attitude isn't the sole, or even primary cause of burnout - just that it doesn't help.

You're well within your right to disagree, of course, but IMO...

Pussyfooting around: "Your code has a lot of good things about it, great job! What would make it even better, is if - and I'm not saying you have to do it this way, please don't think of this as a critique - you looked at possibly optimizing the naming of your functions so that they flow a bit more consistently with other similar functions and enable more effective review..."

Direct, un-softened blows: "I couldn't read your code because the names don't follow established kernel logic. Rejected until that is fixed."

Needless drama: "Your idiotic code is so hard to read I could never even begin to include it, your function names are moronic, if you make it less disgusting then I can even look at the rest without puking"

I think only the first two are "professional", and only the last two are "helpful"...so I don't see anything wrong with shooting for the intersection of professional *and* helpful.

No, the first is just trying too hard to be polite. I would know, I used to write emails exactly like this until my boss told me to knock it off and go straight to the second method.

[cb88]

No, the first is just trying too hard to be polite. I would know, I used to write emails exactly like this until my boss told me to knock it off and go straight to the second method.

1 is written by some guy that thought Steven Covey was the best thing since sliced bread haha... "The key is not to prioritize what's on your schedule, but to schedule your priorities." HORF.....

[Daktyl198]

this article only implies a poor interaction if one seeks to look into kent as a bad person. Read the mailing list.

Ignoring kernel standards and pushing to include garbage code into the core kernel outside of your driver thus forcing other maintainers to look through a hacked together PR is, IMO, a "poor interaction". Even if it's not a social one. He wasted Linus's time with this PR and this is the 2nd or 3rd time recently he's straight up ignored Kernel procedures/etc.

My main point is that I never seem to see other names appear so frequently as having had a run in due to either poor social or code interactions. I'm not saying he's a bad guy, but I am saying maybe he shouldn't be so high up in the kernel dev tree?

[Quackdoc]

Ignoring kernel standards and pushing to include garbage code into the core kernel outside of your driver thus forcing other maintainers to look through a hacked together PR is, IMO, a "poor interaction". Even if it's not a social one. He wasted Linus's time with this PR and this is the 2nd or 3rd time recently he's straight up ignored Kernel procedures/etc.

My main point is that I never seem to see other names appear so frequently as having had a run in due to either poor social or code interactions. I'm not saying he's a bad guy, but I am saying maybe he shouldn't be so high up in the kernel dev tree?

the point of the PR is because some of the XFS guys stated they wanted to share code with bcachefs... He didn't waste time, he got valuable input, which one would know if they read through the Mailing list. Linus isn't against pulling code out into a library, he is against code he doesn't like. Linus Never told him to not do it again, he never told him he is wasting peoples time.

He said and I quote

And maybe xfs even wants to copy that code. I don't care, it seems
stupid, but that's a filesystem choice.

But if we're making it a generic kernel library, it needs to be sane.
Not making people do 64-bit square roots and 128-bit divides just for
a random statistical element.

None of this even remotely implies ignoring kernel standards, forcing maintainers to look through something hacked together, infact, Linus called it "Over engineered" which is the exact opposite.

The talk on the mailing list is technical. There is nothing wrong about that.

[dralley]

Ignoring kernel standards and pushing to include garbage code into the core kernel outside of your driver thus forcing other maintainers to look through a hacked together PR is, IMO, a "poor interaction". Even if it's not a social one. He wasted Linus's time with this PR and this is the 2nd or 3rd time recently he's straight up ignored Kernel procedures/etc.

My main point is that I never seem to see other names appear so frequently as having had a run in due to either poor social or code interactions. I'm not saying he's a bad guy, but I am saying maybe he shouldn't be so high up in the kernel dev tree?

I think Linus can handle himself without random people parasocially appointing themselves guardians of his time and honor. Lots of new subsystems have growing pains like this. The AMDGPU drivers had a ton of drama on both technical and process grounds - it got worked out over time and eventually everyone saw massive benefits.

So chill out, perhaps? Why do you feel the need to make criticisms that even Linus isn't making? Are you actually trying to understand the full context and forming a personal opinion based on technical merit, or are you dogpiling just because?

[hyperchaotic]

Linus used to be worse with his words, but the reality is that he just doesn't soften the blow. If your code is awful to look at, let alone run, he will let you know. It's far better than somebody pussyfooting around and not really telling you what's wrong so you never know what needs fixing. Linus will call the code disgusting, then tell you exactly which part of it is bad and why so that you can fix it.

In the large professional organizations where I've worked subsystem owners were able to say what they didn't like without needing hyperbolic intensifiers. A review kept in a professional tone pointing out the issues is not "pussyfooting". No verbal "blow" was needed because if they didn't like the submission it was simply not going to be accepted into the code line and that's really already the strongest statement/issue/blow.

Obviously as for Linus, he's the owner and can say what he wants, I don't mind. I'm just disagreeing with you that it's necessary, not getting the patch accepted until comments are addressed really is enough.

[fitzie]

Kent is really heading for some serious burnout. On the one hand, his efforts are making improvements for filesystems in general, but on the other hand, he turns every thing into a battle. for example, it's not good enough that he's got subvolume added to statx call, he wanted it added to 6.9 at the last minute. even on technical stuff he's not doing himself any favors. doing writes without the inode lock will probably cause issues that he'll have to debug, and people advised him against it, but he's doing it anyway. this is ontop of now zstd and lz4 issues that for some reason the compression library maintainers aren't helping him with. and of course there is the unnecessary insults and rudeness, which we're not suppose to talk about anymore.

I don't think Kent will abandon his project, but somethings gotta give.

[Daktyl198]

I think Linus can handle himself without random people parasocially appointing themselves guardians of his time and honor. Lots of new subsystems have growing pains like this. The AMDGPU drivers had a ton of drama on both technical and process grounds - it got worked out over time and eventually everyone saw massive benefits.

So chill out, perhaps? Why do you feel the need to make criticisms that even Linus isn't making? Are you actually trying to understand the full context and forming a personal opinion based on technical merit, or are you dogpiling just because?

Not sure why you think observation of a behavior pattern of some random dev means I'm somehow parasocial or simping for Linus? I'd say the same thing if he wasted the time of any maintainer, not just Linus. It just so happens that for some reason his patches go straight to Linus. And again, my comments are not about this particular incident, but about a repeated pattern of behavior I'm noticing from this one particular developer. It was merely an observation, but people here seem to not take kindly to people possibly not liking anybody who works on the kernel, unless it's Linus in which case it seems plenty of people hate him lol.

It could be that plenty of kernel devs have instances like this all the time and Phoronix just doesn't report on them. But multiple articles about the behavior of this single dev in less than a month leads to opinions, especially when he's working so high up in the dev tree on the kernel.