@warthog9 Many thanks to you and
@monsieuricon 's work here and your continued work to keep vger alive all these years, it's one of the primary reasons that Linux development works so well.

Ok, Vger's MX is heading off to point to subspace on Thursday. Web services are staying put for now, so if you link to / use Vger it's staying put (possibly with a massive OS upgrade coming).

The fundamental infrastructure isn't going anywhere even if it has to change it's name, and should lists not want to head off to subspace, infradead, etc I've got https://vger.email up and running and capable of picking things up should anyone want to jump.

End of an era, Vger's been independent of kernel.org from it's start, but it's a non-trivial set of lists that literally keep the Linux kernel community moving, and has since it's inception. It's realistically needed an upgrade to deal with a plethora of problems, and frankly various large e-mail providers have made it nearly untenable to keep doing without it nearly being a full time job (at least at the scale that Vger's at)

It would be very silly to install and boot the stable kernel instead of the usual latest rc, just because it has some specific version number. But stable kernels need testing too!

Dirk: "Are you worried about bugs from LLM hallucinations getting into the #Linux kernel?" Linus: "Well I see all the bugs that come in without LLMs, and so, no I don't." (Paraphrasing the exchange)

Little known fact: first kernel releases were shipped via the postal service.

@oleksandr @kernellogger @vbabka You can't do that, as many many developers do not properly tag real bugfixes with cc: stable, which is why we now take anything with Fixes: on it, when they seem sane.

Again, the patch that caused you problems here was marked this way so that it did get some "soaking" in linux-next and and delayed the stable backport for a few weeks on purpose. It flowed into stable into the correct way, this is as designed.

Well, except for the breakage, but that's what normally happens with hardware, go blame the vendors for that :)

@oleksandr @kernellogger That commit was tagged that way so it would be properly backported, if it's buggy then please let the developers know about it!

@oleksandr What do you mean by "properly reviewed"? They have all passed the normal review process in that they are in Linus's tree. If they are good enough for the next release, why are they not good enough for the previous one?

And as always, reviews for things that you think should not be included are greatly appreciated, we can't do any of this without you!

If you enjoy the hairiest of bug hunts with a thrilling conclusion, this one is for you. The hunt and hair pulling:

https://lore.kernel.org/regressions/480932026.45576726.1699374859845.JavaMail.zimbra@raptorengineeringinc.com/

and the conclusion:

https://lore.kernel.org/regressions/1105090647.48374193.1700351103830.JavaMail.zimbra@raptorengineeringinc.com/

Hats off to Timothy for seeing this one through to completion!

So, you want to read LKML with Gmail (experimental, testers needed)

https://lore.kernel.org/workflows/20231115-black-partridge-of-growth-54bf2e@nitro/

@exi @kernellogger We will finally get to relax at that time. Or at least we can look forward to the potential to relax, providing us hope when buried neck-deep in stable backports...

@vegard @kernellogger Ah, so back in February we made it 4 years, not 2, so why did everyone freak out a month ago thinking it was going to be 2 years?

Math with dates is hard :)

@kernellogger Yes, that's why the dates are like this.

And I just realized, we never publicly said anything about "2 years support for LTS", the kernel.org page has always had longer dates, all we said was "we will not be doing 6 years anymore".

So no one actually looks at the documentation we write (i.e. the web page), AND I didn't even remember that we had written that back in February of this year, this feels like a "write once, read never" type of file...

So many truths are hidden,
So many facts untold,
Queries left unbidden,
Concealed below the fold.

My head droops to the table,
But I must remain informed:
"Is the kernel stable?"
"How is babby formed?"

RFC for the replacing the Linux kernel #Android #Binder driver with a fully functional #Rust version:

https://lore.kernel.org/lkml/20231101-rust-binder-v1-0-08ba9197f637@google.com/

All the talks from Embedded Recipes 2023 are now online, including "The TTY Layer: the Past, Present, and Future" by @gregkh https://www.youtube.com/watch?v=g4sZUBS57OQ&list=PLwnbCeeZfQ_Mi7gjUpLZxXGOcEBS_K8kH&index=5 #er2023

@davidrevoy @standingpad Use email, that's how the kernel is developed and how bugs are reported, send it to the author of that commit and the mailing list listed in the MAINTAINERS file for the subsystem.

No need to file some ticket in some random web form with some odd account, email. It's simple, and easy (note, turn off HTML mode for it please.)

Good luck!

@jani The DCO does cover it, it is just that people don't seem to actually understand where the information from these "AI" tools is coming from for some reason...

This came up in a private thread about a kernel patch review where the contents were created with an "AI" tool, so I figured I might as well put it somewhere a bit more public as people don't seem to really understand the issues involved:

My policy is that I do not take any output of any "AI" tools unless the providence of the data that was used to feed the AI tool can be proven to be under the proper copyright rules as to be compatible with the GPLv2 license.

So in other words, nothing from chatgpt at all, that's obviously full of copyrighted works that are not allowed to be reused in this manner.

@stefanct @kernellogger @LWN We'll figure it out eventually, give us some time :)