Linus Torvalds On Linux 6.8 DRM: "Testing Is Seriously Lacking"

[okias]

Since 6.6 we have some open DRM CI built on GitLab CI shared with Mesa3D. Intel needs to start using it in pre-merge...

edit: Mangogeddon oh, I see you described it very nicely. Just to extend, it's not only AMD. It's Freedesktop which hosts testing for AMD, Intel, ARM, Vivante, virtualizations, etc.

[NotMine999]

Linus is getting soft with the age.

Linus come on, you were the boss.

We can thank all of the thin-skinned whiners who demanded Linus BE NICE rather than have to deal with his unvarnished, honest, direct opinions on stuff.

So Linus was partly neutered in an anger management class and then returned to us in this condition.

Let's face it - writing good kernel code, like making laws and sausage (which are sometimes the same thing) is a process that you do not want to observe.

[gentoofu]

The kernel does have a significant amount of automation around CI testing. Most of this tests stuff that's already in various kernel branches for regressions. However, subsystem maintainers are largely trusted with testing their own code prior to it getting merged into Linus' branch (where it would be tested by CI and Linus himself). AMD/Freedesktop has a CI farm of their own and support for this was merged into 6.6. The issue seems to be that Intel isn't testing their own contributions to the kernel, which is a REALLY bad look for them.

It's ironic because David Airlie was with Intel a few days before that post, ranting in their oneAPI meetup about challenges in the Linux GPU compute stacks. I'm looking forward to hearing about challenges in checking whether the code builds before pushing upstream.

[NotMine999]

Well, he's right... pushing non compiling code and an #include of .c file demonstrate rush in doing things. It is also quite irrespectful for the kernel maintainers that should review them because it wastes their time.

I wonder how it ever got to a kernel maintainer with authority to send the pull to Linus.

If that maintainer heads up the code branch where this code belongs, then I would demote that maintainer all the way back to mailing list janitor.

[TNZfr]

Linus is right, the include of a C file should not exist, and even less in an H file.
Due to the importance of the kernel in the operation of a PC, rigor in respecting the programming language and its practices is essential.

[Dr_ST]

Why don't you suggest this brilliant idea in their mailing list? They are friendly and welcoming to ideas like this and will totally not tell you: Talk is cheap. Show me the code

Too big, won't pass :-)

[elatllat]

And why the %^!@$% are header files used at all instead of rust!

[mdedetrich]

Why isn't there some basic form of CI so that nothing gets merged unless it builds, or am I missing something really obvious here?

Like I haven't contributed to the Linux kernel, but I am involved my many open source projects, one of which I am a core maintainer on a non trivial project (talking ~5-10 millions LOC) and every single project has some CI so that whenever a pull/merge request is made, it you know, compiles the project and runs some tests and its actually been setup that you cannot merge unless it successfully builds.

The kernel seems to have some insanely antiquated processes/ways of working.

[Mangogeddon]

Why isn't there some basic form of CI so that nothing gets merged unless it builds, or am I missing something really obvious here?

Like I haven't contributed to the Linux kernel, but I am involved my many open source projects, one of which I am a core maintainer on a non trivial project (talking ~5-10 millions LOC) and every single project has some CI so that whenever a pull/merge request is made, it you know, compiles the project and runs some tests and its actually been setup that you cannot merge unless it successfully builds.

The kernel seems to have some insanely antiquated processes/ways of working.

The linux kernel is old-school. It's developed over mailing list with many separate git trees. Pull Requests are literally someone sending an email to the mailing list asking Linus to do a merge from their git server. They'll send him the DNS name of the git server to pull from and a ref or commit that he should merge with and he'll run git commands locally to pull to his local environment, fix any merge conflicts, and then push to the "official" Linux kernel tree. That git tree isn't running any fancy Git frontend like Github or Gitlab, it's literally running with the built-in HTTP/SSH support that's built into the git CLI. So there's no real integration point where you can even hook up a centralized CI service.

Why is it like this? Because the kernel is one of the biggest open source projects there is and nothing else scales (especially nothing open source). The kernel sees thousands of contributors for even a single release, singular bugfix releases (released twice a week usually) usually see hundreds of fixes. The long-time kernel developers have scripts to automate their mailboxes and they are very conservative, many of them have been doing this for decades.

[J.King]

We can thank all of the thin-skinned whiners who demanded Linus BE NICE rather than have to deal with his unvarnished, honest, direct opinions on stuff.

The kind of attitude Torvalds used to display is just not appropriate in a workplace setting. When Torvalds is managing the kernel, he's working, and he's working with representatives from dozens of major corporations. A modicum of decorum is warranted.

I don't want to be sworn at or witness someone have an angry breakdown at work. Work is stressful enough without extra drama. Torvalds has realized this, and I for one am happy he has. He can be (and is) acerbic without being abusive.

I don't think he's been neutered at all. He's just using his outside voice now.