Linux 6.12-rc2 Released With Initial Batch Of Fixes

[PuckPoltergeist]

Stop spreading smears and fabrications, he only legitimately broke the code once and that was due to big-endian'ess. The other time it wasn't his fault, it was actually Christians (Linus was wrong here, but seeing as you have an issue with reading you didn't appear to get this part).

I'm speaking about the NOFAIL-changes, that would affect XFS in serious ways

[PuckPoltergeist]

Please stop posting FUD.

-v please

[OneTimeShot]

Kent already addressed this in the lkml, go read it. The tl;dr is that since qemu emulation of big-endian is so slow, it takes literal ages for the tests to run in such a setup, its entirely impractical.

Actual TLDR - other people do this just fine. I used to do it myself in the past, and computers are much faster today. It's not like you sit and watch the code build. If this guy is as smart and godlike as everyone says, why doesn't he know how to set up Jenkins, QEMU, unit tests and cross compilation? It only took me a week or two.

Or maybe he could, you know, just work with the dumb process like the rest of us mortals have to?

[Pranos]

If his changes would only affect his part, this wouldn't be a problem. But his changes are relevant for others too and break existing code. And as this very smart guy doesn't listen to other devs and just says they're producing crap and should adopt his changes, not only Linus gets angry but other devs are pissed too.

Please stop posting FUD.

[mdedetrich]

It's completely trivial to got to qemu.org and download any number of big-endian emulators.

Kent already addressed this in the lkml, go read it. The tl;dr is that since qemu emulation of big-endian is so slow, it takes literal ages for the tests to run in such a setup, its entirely impractical.

As the code didn't even compile he doesn't even need to do that much... just change the -march compiler flag and check that some kind of binary file pops out. We're not talking about some obscure bug that needs particular hardware to reproduce...

Thats not how it works, you actually have to run the outputted binary of the kernel image to see whether it works or not which means you need to emulate it which is the exact issue.

If his changes would only affect his part, this wouldn't be a problem. But his changes are relevant for others too and break existing code. And as this very smart guy doesn't listen to other devs and just says they're producing crap and should adopt his changes, not only Linus gets angry but other devs are pissed too.

Stop spreading smears and fabrications, he only legitimately broke the code once and that was due to big-endian'ess. The other time it wasn't his fault, it was actually Christians (Linus was wrong here, but seeing as you have an issue with reading you didn't appear to get this part).

Shall we start a campaign and get our pitchforks against Christian now since he broke the build?

[PuckPoltergeist]

There is a process for code submission that involves a lot of "soaking time" and high latencies, so one guy bypasses that process because he writes code faster than those processes work and following those processes would incur extreme delays. Instead, the guy tests his code to the same standards on his own, but his coverage is not ideal and mistakes slip through and anger Linus.

If his changes would only affect his part, this wouldn't be a problem. But his changes are relevant for others too and break existing code. And as this very smart guy doesn't listen to other devs and just says they're producing crap and should adopt his changes, not only Linus gets angry but other devs are pissed too.

[OneTimeShot]

The only time where he legitimately did break the build for the kernel was because of a issue with big-endien systems, and as a single developer its quite difficult to get such a machine because they don't build general purpose big-endien machines anymore (the last such manafactured machines, such as those with PowerPC are literally many decades old, and on the other end you have ibm-z mainframes).

It's completely trivial to got to qemu.org and download any number of big-endian emulators. As the code didn't even compile he doesn't even need to do that much... just change the -march compiler flag and check that some kind of binary file pops out. We're not talking about some obscure bug that needs particular hardware to reproduce...

[mdedetrich]

Can someone explain the bcachefs thing? The only I've been able to take away from this : There is a process for code submission so the code is tested against standards to make sure it doesn't break things which may take a while, but one guy bypasses that established process?

The more accurate summary is that the process is not an actual rule but rather a rough guideline, and the current processes are terrible for new features that have a lot of code churn (which bcachefs is).

To put things more concretely, almost almost every other major OS project has nightly build against their current in-progress branch where patches get regularly merged (in this context its fs-next). Instead the current Linux mechanism for getting a proper cross build with your changes is cumbersome and impractical and this is what Kent is battling against. The only time where he legitimately did break the build for the kernel was because of a issue with big-endien systems, and as a single developer its quite difficult to get such a machine because they don't build general purpose big-endien machines anymore (the last such manafactured machines, such as those with PowerPC are literally many decades old, and on the other end you have ibm-z mainframes).

Do note that unlike people that just whine, he is also actively trying to improve the situation (i.e. he is currently setting up a CI for fs-next)

I've no way to determine if the guy submitting the code is so experienced and good at what he does that it shouldn't be an issue. But then again, anyone can make a mistake or typo once in a while.

It is genuinely the case that Kent is insanely smart, he is one of the smartest long time kernel contributors. Its because of this plus him not being a pushover that is causing some tension, because he is actively reaviling current extremely disfunctional processes. Of course he makes mistakes, but it is a fallacy to characterise this as him not testing/building stuff. He never submitted code that wasn't tested/built by himself, the only gap is with big-endian but I previously just explain why this is such an issue.

[intelfx]

Can someone explain the bcachefs thing? The only I've been able to take away from this : There is a process for code submission so the code is tested against standards to make sure it doesn't break things which may take a while, but one guy bypasses that established process?

There is a process for code submission that involves a lot of "soaking time" and high latencies, so one guy bypasses that process because he writes code faster than those processes work and following those processes would incur extreme delays. Instead, the guy tests his code to the same standards on his own, but his coverage is not ideal and mistakes slip through and anger Linus.

That guy also works his ass off to set up an alternative process that would ensure the same standards with better coverage and better latencies, but other maintainers mostly don't care so it takes longer than expected.

[OneTimeShot]

There is a process for code submission so the code is tested against standards to make sure it doesn't break things

The summary is the usual: Everyone makes mistakes, but not everyone learns from them. There are 1000s of people developing on Linux, so no matter what you're doing, don't rock the boat because people are busy. Making other people's lives easier ultimately helps yourself.

Shrug, can't some folks that are tired of having to deal with old hardware simply fork and do a version that, while mainly staying in sync with Linux, drops the whole backward compatibility for anything older than 'x' generations of hardware? Then they can manage code submission any way they want?

If you get tired of dealing with old hardware, kernel development and device drivers is not what you should be doing with your life. At a certain level, Linux is "mature" in that it provides a UNIX environment that itself was stable in the 1970s. It may no longer be feasible to run UNIX with 64kb of RAM, but realistically anything in the last 35 years is going to be fair game to get to a command line...