Linux 6.12-rc2

posted by Roy Schestowitz on Oct 07, 2024,
updated Oct 11, 2024

Hmm. I have had this mental picture that usually rc2 tends to be one
of the smaller rc's because people take a breather after the merge
window, and/or because it takes a while before people start finding
issues.


But at least this release doesn't seem to show that pattern, and I
went back and did some stats on older 6.x releases, and from a quick
look it looks like it's really only true about half the time. Some
rc2's are indeed fairly small, but not all are. I guess I should have
run the numbers before.


Anyway, this isn't one of the small rc2's. But looking at historical
trends, being a bigger rc2 isn't _that_ unusual, and nothing in here
looks all that odd. Yes, the diffstat may look a bit unusual, in that
we had a global header renaming (asm/unaligned.h -> linux/unaligned.h)
and we had a couple of reverts that stand out as spikes in the stats,
but everything else looks nice and small. In fact, one other
noticeably bigger spike in the diffstat is just due to some folio
documentation updates, not any code changes.


At about a quarter of the diffs, the filesystem changes are a bit
bigger than usual (and would actually have been bigger than the driver
changes if it wasn't for one of those reverts), but that's probably
just a random timing effect. I expect I'll be getting more driver
updates next week.


Anyway, on a completely different note: I try to make my merge commit
messages be somewhat "cohesive", and so I often edit the pull request
language to match a more standard layout and language. It's not a big
deal, and often it's literally just about whitespace so that we don't
have fifteen different indentation models and bullet syntaxes. I
generally do it as I read through the text anyway, so it's not like it
makes extra work for me.


But what *does* make extra work is when some maintainers use passive
voice, and then I try to actively rewrite the explanation (or,
admittedly, sometimes I just decide I don't care quite enough about
trying to make the messages sound the same).


So I would ask maintainers to please use active voice, and preferably
just imperative.


Put another way: I'd love it if people would avoid writing their
descriptions as "In this pull request, the Xyzzy driver error handling
was fixed to avoid a NULL pointer dereference".


Instead write it as "This fixes a NULL pointer dereference in .." or
particularly if you just list bullet points, make the bullet point
just be "Fix NULL pointer dereference in ..".


This is not a big deal, I realize. But I happened to try to rewrite a
few of these cases the last week, and I think simple and to-the-point
language is better. The imperative version of just "Fix X" is about as
clear as it gets.


              Linus

Read on

Update

LWN:

• Kernel prepatch 6.12-rc2

  Linus has released 6.12-rc2 for testing. Anyway, this isn't one of the small rc2's. But looking at historical trends, being a bigger rc2 isn't _that_ unusual, and nothing in here looks all that odd. Yes, the diffstat may look a bit unusual, in that we had a global header renaming (asm/unaligned.h -> linux/unaligned.h) and we had a couple of reverts that stand out as spikes in the stats, but everything else looks nice and small.

Also:

• Git grumpy: Torvalds complains of passive voice in merge commit messages

  In a recent mailing list update, Linus Torvalds expressed frustration over passive voice in commit messages, urging developers to adopt a more active and clear communication style.

More ad hominem:

• Linus Torvalds declares war on the passive voice

  Picture this. A developer submits a patch to improve the kernel's performance, only to be met with the scornful gaze of Linux chieftain Linus Torvalds, who declares: "Ah, but your participle is dangling! How do you expect the kernel to thrive under such conditions?"

  "Would that I had established a style guide prior to this process," muses the supremo, slipping into the pluperfect subjunctive mood, a place of regrets where few happy things dwell.

  OK, that's not exactly what happened, but the imaginary dialog made us laugh. We started imagining the exchange after spotting Torvalds getting a bit worked up over grammar on Sunday night on the Linux Kernel Mailing List. He was lambasting the grammatical rather than the coding syntax of contributors. The problem? Devs' use of the passive voice.

Less personal:

• Linux Kernel 6.12 Prepped for Superior Scheduling, Real Time Ops

  The Linux community is preparing to release version 6.12 0f the Linux kernel. The 6.12 version is currently in the “release candidate” phase, with 6.12rc1 available as of Sept. 29, 2024. While this kernel release may not include broad steps forward, it does include some interesting and useful features that demonstrate the forward motion of this fascinating OS kernel.

  The Linux 6.x kernel brought support for real-time capabilities and kernel scheduling, differentiating it from the previous 4.x and 5.x implementations.

Back to ad hom:

• Linux creator complains about developers who write commits incorrectly on GitHub

  Linus Torvalds, the creator of the Linux operating system, announced the Linux 6.12-rc2 kernel and paid special attention to how to properly write commit notes on GitHub about changes to the kernel. This was reported by The Register.

  He is not satisfied with the fact that many programmers use the passive voice in English when describing changes in updates. The developer tries to be consistent in describing new features and uses the active voice everywhere.

Now they are mainstreaming it in Slashdot:

• Linus Torvalds Asks Kernel Devs To Write Better Git Merge Commit Messages

Network World:

• Linus Torvalds annoyed by passive language in commit messages

  The latest release candidate of Linux 6.12 was announced over the weekend, promoting some comments about grammar from Linux founder Linus Torvalds. He took the opportunity to express some irritation when developers use passive, rather than active, language in their commit messages, which he believes is less clear, Neowin reports. A commit message is a short description that developers write when they save changes to a version control system.

  “I try to make my merge-commit messages reasonably ‘coherent’, so I often edit the pull request language to fit a more standardized layout and language usage. It’s not a big deal, and most of the time it’s literally just spaces so we don’t have fifteen different indentation models and bulleted list syntaxes,” wrote Torvalds. He continued...