Erst vergangene Woche hatte Linus Torvalds bemängelt, dass die private Mailingliste für die Kernel-Sicherheit derzeit kaum zu handhaben sei, da immer wieder per KI gefundene Sicherheitslücken mehrfach gemeldet werden und so die Liste überschwemmen.
Zu spät, zu trivial
Am Pfingstwochenende hat Torvalds Linux 7.1-rc5 veröffentlicht und in der Release Note angekündigt, dass er künftig strenger gegen »sinnlose Pull Requests« vorgehen werde, von denen viele durch KI-Code-Reviews ausgelöst werden. Hintergrund ist, dass rc5 um einiges größer sei, als dieser Release-Kandidat üblicherweise in der Vergangenheit war. Torvalds meint, dass diese Pull Requests zwar Fehler beheben, diese aber meist so trivial sind, dass sie in einem so späten Release-Kandidaten nichts zu suchen haben.
Härteres Durchgreifen
Er würde diese Einreichungen lieber im zweiwöchigen Merge Window zu Beginn eines Entwicklungszyklus oder im Linux-Next-Zweig sehen, wo sie dann im nächsten Kernel aufgegriffen werden können. Die jetzige Praxis erhöht die Komplexität zu einem Zeitpunkt, wo sich die Entwicklung einer neuen Kernel-Version dem Ende zuneigt. Deshalb werde er »sinnlose Pull Requests mit Korrekturen, die einfach nicht so wichtig sind, ablehnen«. Diese Phase der Entwicklung sei für das Auffinden von Regressionen gedacht, nicht für solch triviale Korrekturen.
Dauerthema
Diese Einreichungspraxis ist ein Kernel-Dauerthema, das Torvalds bereits lange vor dem KI-Boom ärgerte, wie ein Tread aus dem Jahr 2005 belegt. Erst im August 2025 hatte er Patches für RISC-V für Kernel 6.17 abgelehnt, weil sie zu spät kamen und zudem »Schrott« waren.
Fehler sind Fehler und Pull Requests auf später zu verschieben löst das Problem nicht wirklich, auch wenn es verständlich ist, dass sich Linus damit erst einmal Luft verschafft.
Das AI jetzt für eine Häufung der Meldungen sorgt, kann kaum verwundern. Langfristig könnte AI jedoch auch dazu beitragen Fehler von vornherein zu vermeiden und sich damit recht positiv auf die zukünftige Entwicklung des Kernels auswirken.
In meinen Augen ist es eine Lösung, wenn Pull Requests im zweiwöchigen Merge Window eingereicht werden. Genau dazu ist es da. Dass die KI-Tools an verschiedenen Stellen der Kernel-Entwicklung hilfreich sein können, hat Torvalds ja bereits bestätigt, ihm geht es um den geordneten Ablauf, da ja die Frequenz solcher Einreichungen eher zu- als abnehmen wird.
Ein neues Mainline-Release hat zwei Phasen:
Im zweiwöchigen Merge Window werden neue Funktionen, Treiber, ect. eingebracht. Danach gibt es die Stabilisierungsphase mit den Release Candidates zur Fehlerbehebung.
Wahrscheinlich bezieht sich Linus lediglich auf solche Pull Requests die nicht die neuen Funktionen betreffen, aber auch gleichzeitig so trivial sind, dass deren Korrektur bis zum nächsten Release aufgeschoben werden kann.
Wenn das aber nicht explizit gesagt wird, dann ließt sich für mich die Meldung etwas widersprüchlich.
Da hat er vollkommen recht, das bringt viel zuviel Unruhe rein und macht das Ganze unuebersichtlich.
Fast erfrischend finde ich, dass ein Linus T. noch richtige Erwartungen an Beitragende stellt.