Linux 6.12-rc2
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
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:
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...