Linus Torvalds On Linux 4.19: "This Merge Window Has Been Horrible"

[geearf]

I'm always impressed by how much Linus knows about the kernel, I mean it's something many many devs work on, not just him, and yet every now and then he quickly finds issues in random PR.

I also love how he'll refuse stuff on technical grounds, since he's tied to no business.

[computerquip]

I need to agree with Linus, including as dependency some currently rejected features is very non-ethical.

Every fork should be based on Linus tree, and not some custom one with non-merged features.

It doesn't matter how good or bad is this feature, including non-merged features of libnvdimm is very unprofessional.

I have no clue why 9 people liked your post but it's not unprofessional at all. In a normal code base, it's common to base your feature onto another feature to avoid a merge conflict if one is making changes to a similar piece of code. That sort of thing isn't very popular obviously in the Linux kernel (given its very sensitive nature) but it's not very intuitive to *want* merge conflicts. Linus is basically asking for him to cause a merge conflict on purpose which is quite the opposite of what you would normally hear. It depends on the project and how vital each change can be.

It was surprising that the tree the patchset was rebased on was rejected. It was rejected for one mistake, the mistake was almost instantly fixed and re-submitted after Linus yelled at the developers about it, and then ignored for days now pending a more scrutinized review probably now that it's thrown red flags.

What I don't understand about your post is that Linus' reaction would get him in trouble in a normal work environment. He's certainly in a special position where he's controlled and moderated by no one except himself, which may be an advantage. He's also very talented and ridiculously smart... but to say he's professional is ridiculous. His words undoubtedly cause bitter emotions unnecessarily which most don't care for.

[makam]

If you don't want to get yelled at make sure your code is good.

If you still think your code is good, always be prepared to yell back. Sometimes it is good to have bark with your bite.

[jacob]

lunix is gonna go to shit for sure whenever linus kicks off

Probably not go to shit as such, there are too many vested interests for that, but it may explode into a zillion forks and vendor-specific versions that would spell the end of the Linux community. Unfortunately we must realise that it's a very real possibility. The real tragedy is that should this happen one day, there is currently nothing that could replace Linux as the universal FOSS platform.

[WalterCool]

I have no clue why 9 people liked your post but it's not unprofessional at all. In a normal code base, it's common to base your feature onto another feature to avoid a merge conflict if one is making changes to a similar piece of code. That sort of thing isn't very popular obviously in the Linux kernel (given its very sensitive nature) but it's not very intuitive to *want* merge conflicts. Linus is basically asking for him to cause a merge conflict on purpose which is quite the opposite of what you would normally hear. It depends on the project and how vital each change can be.

It was surprising that the tree the patchset was rebased on was rejected. It was rejected for one mistake, the mistake was almost instantly fixed and re-submitted after Linus yelled at the developers about it, and then ignored for days now pending a more scrutinized review probably now that it's thrown red flags.

What I don't understand about your post is that Linus' reaction would get him in trouble in a normal work environment. He's certainly in a special position where he's controlled and moderated by no one except himself, which may be an advantage. He's also very talented and ridiculously smart... but to say he's professional is ridiculous. His words undoubtedly cause bitter emotions unnecessarily which most don't care for.

Well, let me split my answers.

1) libnvdimm was rejected few days ago https://lkml.org/lkml/2018/8/18/274 , so unless it get accepted, is quite a bad idea to PR your code without using Linus master branch, otherwise, you are merging two separate features, adding a lot more complexity to proper debugging and code review. Specially when Linus has strict code and PR standards (https://www.kernel.org/doc/html/v4.1...g-patches.html)
2) Branching is not rocket science, but usually you would wait to merge feature by feature to avoid complex debugging and simplified analysis. To exemplify this, master = A, libnvdimm = B, XArray = C. So, B is based on A, C is based on B. If you want to merge C -> A, you should wait first to get B -> A merged/approved, so C can be fast-forwarded to A.
Not doing this, you are mostly gonna piss off any vcs manager, unless main feature is C, and B is just dependency of C. Not this case, both are completely separate features.
3) If you are doing something stupid and making others wasting useful time, you should get offended and learn about your errors, here words are just words, but is important to acknowledge your mistakes and fix it . Linus usually explodes bad, I agree, but he doesn't explode by every mistake, but mostly by dumb problems, like creating kernel errors and blaming the userspace (https://www.theregister.co.uk/2013/0...rnel_bug_rage/), making regressions (he really hates this) and/or not following Linux Kernel coding style (https://www.theregister.co.uk/2015/1...urbation_rant/), fixing userspace bugs with bad kernel code (https://www.theregister.co.uk/2014/0...evers_dust_up/), etc.

Look, at least Linus is giving an answer (on a very non-polite way), I met many developers who don't waste their time answering stupid issues, just check opensource projects with PR closed without an answer, ton of them. At least he's honest saying many times is not your friend, don't want to be your friend, respect must be earned, he accept himself as not polite person and he specifically wants to keep a clean and healthy code in kernel, just keep it professional. I'm personally OK with his point of view, of course that would be a subjective opinion. https://www.youtube.com/watch?v=JZ017D_JOPY

[Spring]

I have no clue why 9 people liked your post but it's not unprofessional at all. In a normal code base, it's common to base your feature onto another feature to avoid a merge conflict if one is making changes to a similar piece of code. That sort of thing isn't very popular obviously in the Linux kernel (given its very sensitive nature) but it's not very intuitive to *want* merge conflicts. Linus is basically asking for him to cause a merge conflict on purpose which is quite the opposite of what you would normally hear. It depends on the project and how vital each change can be.

It was surprising that the tree the patchset was rebased on was rejected. It was rejected for one mistake, the mistake was almost instantly fixed and re-submitted after Linus yelled at the developers about it, and then ignored for days now pending a more scrutinized review probably now that it's thrown red flags.

In a monolithic product it's not code author's job to merge code. It's a safety principle that programmers should not merge code before kernel maintainers merge it. It's also very common and important to cause conflicts on purpose in programming, it's a way of communicating between programmers and kernel code authors should not communicate between themselves independently from kernel code maintainers.

[pracedru]

Probably not go to shit as such, there are too many vested interests for that, but it may explode into a zillion forks and vendor-specific versions that would spell the end of the Linux community. Unfortunately we must realise that it's a very real possibility. The real tragedy is that should this happen one day, there is currently nothing that could replace Linux as the universal FOSS platform.

Linus is most likely going to retire one day. And before that happens he would have his job transitioned to his replacement. Happens all the time. Some organisations are better at this than others. The worry is that Linus might get into an accident and leave his job early. This is a normal worry of any company that is relying on a single person in that way. But the Linux Foundation will be able to find a replacement in the unlikely case that such a tragedy might occur. Forks of Linux happens all the time. In my view another fork would gain prevalence if people disagree with the direction that Linux I taking. This could happen if Linus isn't there any more, but it would probably take a long time before any one fork would gain a competing user base.

[theghost]

Linus is absolutely right.
And the fact that he needs to explain how branching/rebasing is used to a Kernel developer makes me wonder.

[perpetually high]

Well, let me split my answers.

...

What a solid post. Thank you.

Linus is most likely going to retire one day.

Highly doubt Linus will give up his baby if he is still alive and well. His judgment on certain decisions is unmatched by _anyone_. I mean that. Sometimes you have these figures. Linus is one of them.

If Ruth Bader Ginsburg is 85 and intending to be a SCOTUS Justice into her 90s, I think Linus can maintain the kernel with the help from his other maintainers in his humble abode in Finland

Lastly, Linus is absolutely right. Respect is earned. He's earned every right to act the way he does. It has deeper meaning at times also. The Linux kernel should not be compared to anyone's work environments.

He has high expectations from himself, and anyone who dares contribute to the kernel. You abide by his rules, not vice-versa.

"I get upset, because dammit, I expect better. I don't want to go "oh, this changes core code, let's just skim over the patches" and immediately find something fundamentally broken like this." Linus

[Vistaus]

With how full people can of themselves these days, having someone yell at how bad your work is can be a sobering experience. If things aren't good, they aren't good.

In fact, screaming is needed because of the Chain Of Screaming

https://www.youtube.com/watch?v=G1DSMKGop2o