Linux 6.12-rc2
posted by Roy Schestowitz on Oct 07, 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