| Di seguito sono disponibili le note di rilascio (release notes) relative al file Linux Kernel 6.12-rc3, qualora gli sviluppatori le abbiano rese pubbliche in fase di distribuzione del software. Se la documentazione non è presente o se desideri ulteriori dettagli su Linux Kernel 6.12-rc3, puoi comunque consultare la descrizione del file che include anche la lista dei Sistemi Operativi supportati. |
Linux kernel 6.12-rc3 released
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 |
|
