Torvalds: "Dieser Release Candidate ist riesig"
Linus Torvalds veröffentlicht wöchentlich einen Statusbericht zum Linux-Kernel. In der Meldung vom 2. August 2026 zum sechsten Release Candidate von Version 7.2 fiel der erste Satz ungewöhnlich knapp aus: Dieser Release Candidate sei riesig. Ein Release Candidate ist eine Vorabversion, die vor der finalen Freigabe nur noch Fehlerkorrekturen aufnehmen soll.
Gemessen an der Zahl der Commits, also der einzelnen eingecheckten Änderungen, sei es der größte rc6 seit Jahren, so Torvalds sinngemäß. Und selbst an den Maßstäben der "neuen Normalität" gemessen sei das ein großer Brocken. Eine Woche später wiederholte sich das Bild beim siebten Release Candidate.
"Ich kann nicht sagen, dass ich über die Größe des Ganzen begeistert bin. Aber es ist, wie es ist: die neue Normalität mit vielen Fixes, viele davon aufgrund von Überprüfungen durch verschiedene KI-Tools." (sinngemäße Übersetzung einer Aussage von Linus Torvalds)
Welche Werkzeuge die Entwickler dafür konkret einsetzen, ist nicht dokumentiert. Auch dazu, wie viele der gemeldeten Probleme sich am Ende als Fehlalarm herausstellten, gibt es keine Angaben.
Viele kleine Korrekturen statt weniger großer Baustellen
Inhaltlich sieht Torvalds keinen Grund zur Panik. Nichts wirke für sich betrachtet besonders bedrohlich, es sei einfach nur sehr viel. Der Großteil bestehe aus winzigen Korrekturen, verteilt über nahezu alle Bereiche des Kernels: Treiber für Grafik, Sound und Netzwerk, Dateisysteme, den Netzwerkkern und architekturspezifischen Code.
Drei größere Änderungen hebt er hervor:
| Bereich | Änderung |
|---|---|
| s390/zcrypt | Korrekturen am Krypto-Subsystem der IBM-Mainframe-Architektur |
| btrfs | Rückkehr der Fixup-Worker-Infrastruktur des Dateisystems |
| netfilter ipset | Korrekturen an der Paketfilter-Komponente |
Abgesehen davon handelt es sich laut Torvalds um eine breit gestreute Masse an Kleinigkeiten. Verschoben wird der Release deshalb nicht: Version 7.2 sollte planmäßig erscheinen, sofern nichts wirklich Schlimmes auftaucht. Ein Long-Term-Support-Release mit langer Pflegezusage wird die Version nicht, bringt aber unter anderem ein verbessertes Scheduling für GPUs und CPUs, also eine effizientere Verteilung der Rechenlast auf Grafik- und Hauptprozessoren.
Kein Anti-KI-Projekt, aber auch keine Euphorie
Torvalds' Verhältnis zu KI im Entwicklungsprozess ist gespalten. Er hat sich mehrfach dagegen verwahrt, dass gute Dokumentation schlechten, maschinell erzeugten Code entschuldigt. Und er hat kritisiert, dass die Security-Mailingliste des Kernels durch eine Flut KI-generierter Fehlerberichte kaum noch zu bewältigen sei, viele davon Dubletten.
Gleichzeitig hat er klargestellt, dass Linux nicht zu den Anti-KI-Projekten gehöre. Beiträge, die mit KI-Unterstützung entstehen, sind also nicht ausgeschlossen. Das Muster kennt man auch aus anderen Ecken der Open-Source-Welt: Als im vergangenen Jahr KI-Agenten Open-Source-Projekte auf GitHub unter Druck setzten, war das Problem selten der Code selbst, sondern die Menge an Material, die Maintainer sichten mussten.
Was das für Betreiber eigener Infrastruktur bedeutet
Der Vorgang ist mehr als eine Randnotiz aus der Kernel-Entwicklung. Linux ist die Basis für praktisch jede selbst betriebene Server-Umgebung. Wenn KI-Werkzeuge dort massenhaft kleine Fehler aufspüren, wird diese Basis technisch sauberer. Das ist ein Argument für Self-Hosting, weil die Qualität der Grundlage steigt, ohne dass ein Anbieter dafür eine Rechnung stellt.
Die Kehrseite ist der Wartungsaufwand. Größere Update-Pakete mit vielen kleinen, breit verteilten Änderungen bedeuten mehr Testfläche pro Release. Wer Kernel-Updates in produktiven Umgebungen einspielt, kann sich weniger darauf verlassen, dass ein Punktrelease nur eine Handvoll klar umrissener Punkte anfasst. Regressionstests und ein sauberes Rollback-Konzept werden wichtiger, nicht unwichtiger.
Ob sich dieser Umfang künftig auch auf LTS-Versionen auswirkt, die in Unternehmen typischerweise im Einsatz sind, ist bislang offen. Dazu gibt es keine Aussage aus dem Projekt.
KI findet Fehler, entscheidet aber nicht
Interessant ist die Rollenverteilung: Die KI-Tools liefern Hinweise, die Bewertung und Aufnahme bleibt bei den Maintainern. Genau dort liegt der Engpass. Untersuchungen zu Freigabeprozessen mit KI-Beteiligung zeigen, dass menschliche Kontrolle bei hohem Durchsatz nachlässt und ein erheblicher Teil der Risiken durch Human-in-the-Loop-Prüfungen nicht erkannt wird. Je größer die Patch-Berge, desto relevanter wird dieser Effekt auch für den Kernel.
Für Unternehmen, die auf offene Werkzeuge setzen, ist das eine nützliche Lehre. KI-gestütztes Review lässt sich mit offenen Modellen und Werkzeugen wie Goose als Alternative zu abo-gebundenen Coding-Agenten auch im eigenen Haus betreiben. Der Aufwand verschiebt sich dann aber genauso, wie es beim Kernel zu beobachten ist: weg vom Finden der Fehler, hin zum Sortieren, Bewerten und Testen der Ergebnisse.