[Danjoe4]

> I think Linus should be more respectful of other people

You all need to grow thicker skin. If we're really engineers, we can't dance around criticism. Linus' comment was about the code; he never insulted the developer. If you attach your self worth to the code you write that's your problem.

What would you have him do? Sugarcoat it? "Uh actually sweetie please rework this function it's not quite there".

It's a PR; honest, unbiased feedback on the code (and optionally how to improve it) is the only thing that matters. If the code is garbage then the reviewer needs to say so.

[tverbeure]

It’s a very public email list and whenever Linus has one of these comments, they get widely shared.

Google the name of the receiving engineer. Despite the fact that he was involved in the creation of RISC-V, nearly all of the top results have the name “garbage” in them. I’d be mortified if that happened to my professional reputation. It would mentally destroy me. I don’t have the thick skin to deal with the ridicule of thousands.

For that reason alone I would never ever consider participating in Linux kernel development, and I’d advise others the same.

It is easy to critique others works without turning it into a spectator sport. Other people manage to do it all the time.

As for the “sweetie” part of your comment: there’s a world out there is that more than just black and white. You should try it sometime.

[typpilol]

Wow that's bad. I didn't realize it would affect the seo that badly

[tverbeure]

Yup. And now imagine what the effect would be for some engineer who is not well known for other work.

[croes]

Linus personally criticized your code?

That’s not bad PR for a bad PR

[foreslion]

Here are some words Linus used to describe the submitted code: crazy, stupid, garbage, needs to get bent, incomprehensible.

Would you like to work at a place where these words are used to give feedback? I sure wouldn’t. But maybe I’m a snowflake.

[themafia]

The context is, pull requests of this magnitude were expected before the merge window, and this was sent after and made these modifications to generic header files used in other sub-trees. This has also happened previously.

So the commentary was on more than just the code it was on the entire situation. It was concluded by saying they could do this but not in generic headers and they could try the PR again early in the next release.

That language was not meant to be inflammatory but stern and the door was left wide open for future submissions.

Would I mind this in my workplace? Probably not. Particularly if my boss was a well known programmer with decades of experience and inside knowledge to share with me.

[chris_wot]

The thing is, if he got this patch at the right time, what’s the bet he would have said this is bad code, gave the same feedback but toned it down?

I get the sense that he’s more upset by the timing, and whilst unimpressed with the code, he’s reacting because of the timing. Hard to tell though because of the way that email is written.

[almost_usual]

If it came from an engineer as respected as Linus, sure. Someone who was average at best with a big ego? No.

Context matters here.

[chris_wot]

So if you are a respected peer, it’s fine to abuse others, because you’ll get away with it?

That way allows for tyrants.

[almost_usual]

If it makes me a better engineer and the feedback is valid sure. If they are attacking my personal beliefs or family that is a different matter.

I’m not saying it’s OK for everyone. If folks are unable to extract the same value that’s fine, find advice from someone else.

[deredede]

You can give honest, unbiased feedback without insulting either people or their work.

Software engineering is a collaborative process, not an adversarial one.

[frumiousirc]

> Software engineering is a collaborative process, not an adversarial one.

The collaborative process itself is adversarial. Capitulating to others when their contributions go against one's goal compromises that goal. Sometimes compromise to achieve a lesser goal is better than failing to achieving the full goal. But, when stakes are high (and Linux stakes are enormous) compromised goals are less appropriate. Linux and Linus are in a position not to have to compromise the goal.

[detaro]

In what way would rejecting the code with different wording be "capitulating" exactly?

[timmytokyo]

If you've worked in SWE for long enough, you'll run into this kind of socially maladjusted petty tyrant many times in your career. It's fascinating to see so many of these tyrants exposing themselves in this thread, though.

[frumiousirc]

In what way was I addressing Torvalds' choice of "wording", exactly?

[detaro]

That's the part the comment you replied to had a problem with, so it seemed obvious that your disagreement was with that.

[kabes]

Yeah, but not sure if

> That thing makes the world actively a worse place to live

Is really necessary to get the point across.

[MrJohz]

Doesn't that go both ways? If we're "really engineers", we don't need to use hyperbole to communicate simple ideas like "this isn't on time, nor is it up to the right quality standards, and I'm tired of having to say this so often".

In practice, how we communicate with each other matters, even in fields like engineering. That doesn't mean perfect objectivity all the time (that's not how anyone speaks to each other), but it does mean taking the time to understand how our words are going to be received by the person we're talking to.

Think of it this way: if I wanted to ask you to go to the shop, but instead of saying "shop", I kept on using a gibberish word instead, we'd say that was bad communication. I know you won't understand the gibberish word, so you won't understand what I'm trying to say to you.

The same is true of tone. Tone is part of communication, so when I use a tone of voice that is too aggressive, or too polite and careful, then you can't understand what I'm actually trying to say. Finding the right tone is necessary for good communication. What that tone is will depend on who I'm talking to - with my friends I'll use one tone and with strangers another; with British people I'll phrase things one way, with Germans in a different way.

Fwiw, I understand the communication style on the a Linux mailing list to generally be fairly combative, so if that's the culture Linus has built up, then fair enough if he chooses to communicate that way. Although the danger there of course is that if you only communicate like that and someone new appears who is not used to that culture, then there are going to be translation difficulties that may put newcomers off.

[readthenotes1]

He's describing the code, not the coder.

It is not an attack on the coder, just the work produced.

If we are to infer that any criticisms of our work are criticisms of ourselves then we are in deep trouble as a society

[MrJohz]

Huh, I would have said almost the opposite to that last paragraph. Recognising that I am the person who produced some bit of work, and therefore I am responsible for its quality (and in this case timeliness) is the heart of self-reflection. Without that, how can I ever get better at what I do? If criticisms of my work are completely divorced from any criticism of myself, then I cannot grow, because I am never being criticised.

I feel like there's a middle ground here, where I understand that failures in my work don't necessarily define me, but that I am still responsible for them.

[chris_wot]

You know, you can actually express your feedback without derogatory remarks. You don't need to sugarcoat it. Let's try that message from Torvalds again, without the diatribe and invective:

> No. The quality of this code is dreadful and it came in too late. I asked for early pull requests because I'm traveling, and if you can't follow that rule, at least make the pull requests good.

Slight tweak.

> This adds various poor quality code that isn't RISC-V specific to generic header files.

garbage -> code

> I am extremely upset that you have sent me such badly written code so late in a merge window.

you know, he's not so upset with the code, but he's upset with the timing. What's the bet he might have been a bit nicer if it had been sent in well before the merge window.

> Take for instance this make_u32_from_two_u16() helper function. This function makes code incomprehensible, and actively WORSE than not using it in the first place.

"That thing makes the world actively a worse place to live." but does it? Lots of things make the world a worse place to live in. Disease, crime, DOGE... but does a helper function actively degrade the ability to live in the world?

> If you write the code out as "(a << 16) + b", you know what it does and which is the high word. Maybe you need to add a cast to make sure that 'b' doesn't have high bits that pollutes the end result, so maybe it's not going to be exactly _pretty_, but it's not going to be wrong and incomprehensible either.

See, was that hard? I didn't change any of this.

> In contrast, if you write make_u32_from_two_u16(a,b) you don't know what the word order is. IOW, you just made things WORSE, and you added that helper function to a generic non-RISC-V file. If others people use this, then it will make other code worse too.

I hardly changed this, but I didn't sugar coat it.

> So no. Please don't include these sort of functions in the code. It does not go into generic header files, and it damn well does not happen late in the merge window.

Note I kept in the "damn well".

> You're on notice: no more late pull requests, and no more unrelated code outside the RISC-V tree.

This is fine. Torvalds is upset, for good reason.

> Now, I would hope there's no similar code inside the RISC-V parts, but that's your choice. But things in generic headers do not get polluted by this sort of stuff. And sending a big pull request the day before the merge window closes in the hope that I'm too busy to care is not a winning strategy.

Smallest tweak.

> So you get to try again in 6.18. EARLY in the that merge window. And without the garbage.

No change, even got a chance to use the word "garbage".

Perhaps I should put this in a way that you might enjoy though: Torvalds is a dick in his communication and a stunted human being. His inability to communicate to others makes them feel bad despite the fact they evidently put in a lot of time and effort to make things better and when they make him angry he can be a petty little shithead who has no control over his emotions.

[procaryote]

> Perhaps I should put this in a way that you might enjoy though: Torvalds is a dick in his communication and a stunted human being. His inability to communicate to others makes them feel bad despite the fact they evidently put in a lot of time and effort to make things better and when they make him angry he can be a petty little shithead who has no control over his emotions.

See, you're talking about the person, whereas Linus was talking about the code and the behavior of submitting such code late. Linus' thing is much nicer

[kalaksi]

I see your point but code isn't completely detached from it's writer. Of course, you have to be able to receive criticism and not take it too personally, but I don't think you can just use all kinds of overly harsh and unconstructive language about the code and then claim it's only about the code and doesn't reflect on the author at all, so it's okay. After all, who's the one that writes the "incomprehensible" "garbage code".

[chris_wot]

You can't get more personal than "That thing makes the world actively a worse place to live."

[baobun]

"That is one stunted person" gets there and beyond. It's unwarranted, too.

[rolandog]

The author does have a point; the whole BcacheFS drama was in part because of comments that criticized other filesystem's design (granted, the straw that broke the camel's back where comments alluding to a developer needing to get their head checked out, and some faux-pas like adding a feature when a change freeze was already in place).

[procaryote]

I had the impression it was about repeatedly ignoring the development process, and assuming the experimental bcachefs module moving quickly was somehow more important than the rest of the kernel being stable

[rolandog]

Yes, agreed. Though that's what I meant by "in part": when you read the threads, they derail when Kent takes potshots at other filesystems ... whose developers were CC'd in the mailing list.

To be honest, some of those reactions did feel a bit out of proportion; I am not entirely sure if there could be other reasons for blowing Kent's attitude out of proportion: (Like, does someone stand to benefit that a COW-filesystem without too many sharp edges isn't shipped?).