Linux 7.2.6 führt einen Stable-Schub mit 9.000 Patches an

Greg Kroah-Hartman hat sieben Linux-Stable-Kernel gemeinsam veröffentlicht, die zusammen mehr als 9.000 Patches tragen. LWN.net berichtete am 14. September 2026 darüber, und der Rat dazu ist der übliche: aktualisieren. Bemerkenswert ist die Menge, und Kroah-Hartman hat selbst darauf hingewiesen.

Dieser Schub "könnte einen Rekord für die Anzahl der Patches aufstellen, mit mehr als 9.000 insgesamt zwischen ihnen", schrieb er.

Ein Stable-Kernel ist eine Pflegeversion. Er nimmt einen bereits veröffentlichten Kernel und ergänzt Korrekturen, die in den neuesten Entwicklungskernel eingeflossen sind, ohne Funktionen hinzuzufügen. Dieses Vorgehen heißt Backporting. So kann eine Distribution oder ein Produkt jahrelang auf einer Kernel-Version bleiben und trotzdem Korrekturen erhalten.

Die sieben Veröffentlichungen

Serie	Version
7.2	7.2.6
6.18	6.18.52
6.12	6.12.110
6.6	6.6.157
6.1	6.1.188
5.15	5.15.221
5.10	5.10.270

Linux 7.2.6 trägt mit mehr als 1.800 Patches den größten Anteil allein.

Wie die Zahl sichtbar wird

Die Patch-Zahl ist keine nachträgliche Zusammenfassung. Sie steht in der Betreffzeile der Review-Nachricht.

Bevor ein Stable-Kernel erscheint, schickt Kroah-Hartman den ganzen Satz als Release Candidate an die Kernel-Mailingliste, damit Maintainer und Nutzer ihn testen. Die Nachricht zu diesem trägt den Titel "[PATCH 7.2 0000/1815] 7.2.6-rc1 review" und wurde am 12. September 2026 gesendet. Das 0000/1815 ist die Patch-Nummerierung, die Größe der Serie steht also im Titel der ersten Nachricht.

Dieses Review-Fenster ist der Teil, den man kennen sollte. Die Patches sind Tage vor der Veröffentlichung öffentlich, und das ist das Fenster, in dem eine Regression in Ihrer eigenen Arbeitslast noch gefunden und gemeldet werden kann.

Was das für Entwickler bedeutet

Behandeln Sie die Menge als Planungsfaktum, nicht als Warnung. Ein größerer Schub ist kein Beleg für eine schlechtere Veröffentlichung. Er bedeutet aber mehr geänderte Zeilen, die in einem Schritt auf Ihre Systeme kommen. Und er bedeutet mehr Fläche für eine Regression, die nur Ihnen auffallen würde.

Drei praktische Schritte. Erstens: Finden Sie mit uname -r heraus, auf welcher Serie Sie wirklich sind, und vergleichen Sie sie mit der Tabelle oben, statt anzunehmen, dass Ihre Distribution der neuesten folgt. Zweitens: Wenn Sie etwas mit ungewöhnlicher Hardware oder einem Modul außerhalb des Baums betreiben, testen Sie das auf einer Maschine, bevor es die Flotte erreicht. Module außerhalb des Baums sind hier die häufige Quelle von Überraschungen, denn im Stable-Prozess testet sie nichts.

Drittens: Wenn Sie doch auf eine Regression stoßen, melden Sie sie gegen die Stable-Serie, statt sie lokal zu umgehen. Genau dafür gibt es das Review-Fenster, und eine Korrektur, die aufwärts landet, erreicht alle auf dieser Serie.

Nur eines sollte man hier nicht hineinlesen: Eile bezüglich der Lebensdauer Ihres Kernels. Weder die Ankündigung noch der Bericht von LWN sagt, dass eine dieser sieben Serien das Ende ihrer Pflege erreicht. Nichts hier verschiebt also eine Upgrade-Frist. Dass die Serien 5.10 und 5.15 weiterhin Veröffentlichungen erhalten, ist selbst das nützliche Signal für alle, die ein langlebiges Produkt planen.

Unabhängig davon soll derselbe Baum Gewicht verlieren: Maintainer haben einen Branch, der rund 247.000 Zeilen alten 32-Bit-ARM-Codes entfernen würde. Zusammen gelesen sagen die beiden etwas darüber, wohin die Kernel-Arbeit geht. Korrekturen auf sieben Zweige gleichzeitig zurückzuportieren ist der Preis dafür, Hardware ein Jahrzehnt zu unterstützen. Und tote Plattformen zu löschen ist der Versuch der Maintainer, diesen Preis bezahlbar zu halten.