There's been a long nerd-sniping thread recently here from @monsieuricon where email message-ids were being discussed and generated in semi-interesting ways that ended up detouring me and @brauner into writing up competing python vs. perl scripts to get `git send-email` to properly use our new bespoke message ids:
https://social.kernel.org/notice/AU5IphRPUsQvvkx732

But why does any of this matter? As most everyone knows, Linux kernel development happens through email, and the Message-Id of an email is a unique identifier that is used to track messages in our patch handling tools and archives (see https://lore.kernel.org for the archives.) By crafting shorter-but-still-unique message ids it's easier to reference those messages in other places, and using words is just prettier overall than random UUID values (https://i.redd.it/64gl4t9s52ra1.jpg for an example)

Bonus to all of this is that people don't realize that most of the patches we send out are actually signed and can be validated as coming from the person that sent them. The tool we use for that looks at the body of the email, and a small subset of the Header tags in the email. By providing to the tool our custom Message-Id, that adds yet another portion of the email that is now able to be signed and validated, providing a tiny bit more security overall in the patch submission processes (very very tiny, I know, but it's real, as I found out when I submitted a patch with a broken message-id from what was signed and our tools caught it.)

Anyway, all of that is a long way of showing off a tiny core change to the kernel that allows some core structures to be moved to read-only memory that I've been working on for a few months now. Here's the last portion of that work being sucked off of the email archives and validated as coming from me:

Me: we have 50TB on our backend storage system that stores kernel tarballs, so this should be plenty for the next 5+ years.
@gregkh: challenge accepted!

You get a stable kernel release, and you get a stable kernel release, and you get a stable kernel release!

Hopefully things now settle down to the normal constant crazy pace we are used to (1-2 releases a week), instead of the mass of releases we had in the past few days.

@killyourfm Just a short note, your recent #mixtape playlists have been the soundtrack for my recent kernel development and release work for the past few weeks, great work! Many thanks for sharing them!

"The magic to remember is type [ESC]ZZ to save and exit."
"Yes that is an odd set of things to remember."
"I don't know, historical reasons."
"Yes, graphical editors are prettier, but sometimes you will have to use this."

Parents, don't forget to have the uncomfortable conversation with your children about vim _before_ they leave for college and are exposed to the siren-call of vscode.

Turns out almost no one uses extra-long LTS kernels, so let's slowly unwind from that interesting experiment:

https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=5cca06606a7dcb2a0a6b6a818072b81b21287b3b

b4 0.12.0 is available

Everyone using "b4 send" must upgrade to stop hitting Python email module bugs.

https://lore.kernel.org/tools/20230120165712.rznwonw6nbfhc7fo@meerkat.local/

I've happy to see how well the Steam deck has turned out, and I'm glad to see them get good press for it as well. Long-term maintenance and updates are key and the Valve developers have been doing wonderful with this:

https://www.theverge.com/23513517/steam-deck-long-term-test-valve

Now if only they would switch to use the LTS kernel releases, I'd be totally satisfied.

When you attempt to rebuild the Fairphone 3 kernel on a modern distro (i.e. Arch) and you get a very odd failure when building the kernel modules, install the `aur/ncurses5-compat-libs` package and then all will work properly.

Took me forever to try to figure out what was wrong with the kernel code itself, should have realized it was the host system issue instead. Hermetic Android builds must have come later in the Android release cycle.

The new EU regulation requiring longer "full support" (5 years) for mobile devices is going to be fun!

Companies will have to update their kernel to a newer version over the lifespan of the device in order to stay in compliance.

As I heard recently in a meeting with one Android vendor, "Android updates consist of over 2000 programs updated to the latest version, what's so hard about adding 1 more to it?"

So if the requirement from Android to have a 6 year supported kernel version is now gone, maybe we don't have to do it upstream either? That will make so many people very happy.

Also, Apple has been doing this for a long time for their devices, why do people feel it is somehow impossible? :)

https://ec.europa.eu/info/law/better-regulation/have-your-say/initiatives/12797-Designing-mobile-phones-and-tablets-to-be-sustainable-ecodesign_en

The 4.9.y kernel is finally end-of-life, it is gone from the tracking board.

Me: nobody sends more than 999 patches in a series, so let's "\d{1,3}/\d{1,3}"
@gregkh: [PATCH 6.1 0000/1146]