„The Linux 7.4 Merge Window Is Easily The Largest In Kernel History“ – so lautet die Überschrift, die Michael Larabel bei Phoronix über seine Auswertung gesetzt hat. Hinter dem Satz steckt keine Rhetorik, sondern eine Zahl: 19.671 Git-Commits in einem Merge Window, also in den zwei Wochen nach einem Release, in denen die Änderungen für den nächsten Kernel zusammengeführt werden.
Larabel hat die Commit-Zahlen aller Merge Windows seit Linux 3.1 aus dem Jahr 2011 zusammengetragen. Über viele Jahre lagen die Werte zwischen 12.000 und 14.000, mit einzelnen Ausreißern nach oben. Jetzt sind es fast 20.000. Das ist kein weiterer Punkt auf einer langsam steigenden Kurve.
Was ein Merge Window überhaupt misst
Nach der Freigabe einer stabilen Version öffnet Linus Torvalds für rund zwei Wochen das Merge Window. In dieser Zeit nimmt er die Pull Requests der Subsystem-Maintainer an, also die gesammelten Änderungen aus Treibern, Dateisystemen, Netzwerk, Architektur-Code und mehr. Danach beginnt die Phase der Release Candidates, in der nur noch Fehler behoben werden.
Die Commit-Zahl ist ein grober Indikator für die Arbeitsmenge eines Zyklus. Über Qualität sagt sie nichts, auch nichts über die Bedeutung einzelner Änderungen oder darüber, wie viele Menschen daran gearbeitet haben. Aber sie zeigt, wie viel Bewegung im Projekt steckt.
Eine Großbaustelle ist ein passendes Bild: Alle Gewerke rücken gleichzeitig an, bevor die Bauabnahme beginnt. In den zwei Wochen des Merge Windows wird eingebaut, was fertig ist. Danach wird repariert. Wenn auf dieser Baustelle plötzlich ein Drittel mehr Material angeliefert wird als in den Jahren zuvor, ist das ein Signal.
Der Sprung von 6.19 zu 7.4 in Zahlen
Larabels Liste ist lang, und darin liegt ihr Wert: Sie erlaubt, den aktuellen Ausreißer einzuordnen, statt ihn nur als Schlagzeile zu konsumieren. Schon vor dem Sprung lag das Niveau höher: Linux 7.0 bei 12.468 Commits, 7.1 bei 13.963, 7.2 bei 14.395. Dann 7.3 mit 16.267 und 7.4 mit 19.671.
Der Vergleich mit den früheren Spitzenwerten: Linux 4.9 aus dem Jahr 2016 kam auf 15.095 Commits, Linux 5.8 auf 15.086, Linux 6.7 auf 16.203. Das waren die bisherigen Marken. Dass nun innerhalb weniger Zyklen drei Werte über der alten Bestmarke liegen, ist ein Muster und kein Zufallstreffer.
Larabel weist darauf hin, dass die Zahlen zum Zeitpunkt seiner Auswertung noch nicht endgültig waren. Bis zur erwarteten Freigabe von Linux 7.4-rc1 am selben Tag konnten weitere Commits hinzukommen. Die Größenordnung dürfte sich dadurch nicht verschieben, aber die Messung liegt dicht am Geschehen.
Warum KI und LLMs den Ausschlag geben
Larabel benennt auch die Ursache. Er führt den Anstieg nicht allein auf die wachsende Verbreitung von Linux zurück, obwohl die von Consumer-Geräten bis zu Rechenzentren zunimmt. Ein erheblicher Teil der zusätzlichen Patches geht auf KI und LLMs zurück. Die Maintainer beschreibt er als „completely overwhelmed“ – überlastet durch eine Flut KI-generierter Fehlerberichte und Patches.
Der Unterschied ist wichtig. Wenn ein Projekt wächst, wächst meist auch die Zahl der Beitragenden, und die Arbeit verteilt sich. Hier kommt Arbeit schneller hinzu, als sie verteilt werden kann. Ein Sprachmodell schreibt einen Patch in Sekunden. Ein Maintainer braucht deutlich länger, um zu prüfen, ob der Patch korrekt ist, zum Stil des Subsystems passt und nichts anderes kaputt macht. Die Prüfseite lässt sich nicht im selben Tempo beschleunigen.
Larabel betont, dass sich die Aktivität nicht auf das Merge Window beschränkt. Viele der KI-generierten Beiträge sind Fehlerbehebungen; die erhöhte Commit-Zahl zieht sich deshalb durch den ganzen Zyklus. Linux 7.3 war der erste Kernel, der über einen kompletten Zyklus die Marke von 20.000 Commits überschritt, mit 20.260 Commits von v7.2 nach v7.3. Bei Linux 7.4 wird diese Größenordnung schon im Merge Window erreicht.
Fast 42 Millionen Zeilen Quellcode
Larabel nennt eine zweite Kennzahl: Der Quellbaum des Kernels nähert sich 42 Millionen Zeilen. Diese Zahl wächst fast monoton, taugt aber längst nicht mehr als Maß für Komplexität, weil ein großer Teil aus Hardware-Beschreibungen, Treibern für längst vergessene Geräte und generiertem Code besteht.
Als Größenordnung ist sie trotzdem nützlich. Sie erklärt, warum das Projekt seit Jahren über Skalierung spricht, über Maintainer-Belastung, automatisiertes Testen und Werkzeuge für die Prüfung. Niemand überblickt diesen Baum noch allein. Die Organisation funktioniert über Vertrauen in Subsystem-Maintainer und klare Regeln, wer welche Änderung abnimmt.
Ein zusätzlicher Strom von Beiträgen trifft also nicht auf eine zentrale Instanz, die einfach mehr Leute einstellt, sondern auf ein verteiltes Geflecht aus Verantwortlichkeiten. Dort entsteht der Druck, den Larabel beschreibt.
Die Gegenbewegung hat schon begonnen
Die Reaktion auf die neue Lage ist schon sichtbar, nicht nur in Kommentaren, sondern im Code. Eine Neuerung in Linux 7.4 sollte KI-Rauschen reduzieren – und wurde bereits wieder zurückgenommen, weil sie sich als „crazy beast“ erwies.
Der Versuch, das Problem technisch zu lösen, ist gescheitert, zumindest in dieser Form. Er zeigt aber, dass das Projekt das Problem erkennt. Parallel tauchen vermehrt LLM-Richtlinien in Teilprojekten auf, etwa bei der Vulkan-Treiberentwicklung. Auch auf der Gegenseite wird KI eingesetzt: OverlayFS erhielt viele Korrekturen durch KI-gestütztes Code-Review.
Das ist keine einseitige Überflutung, sondern eine Verschiebung. Dieselbe Technik, die Patches produziert, prüft auch Patches. Ob unterm Strich Qualität gewinnt oder sich nur der Aufwand verlagert, ist offen; viele Maintainer diskutieren gerade darüber.
Was der Rekord konkret bedeutet
Für Anwender ändert sich durch diese Zahl zunächst wenig. Der Kernel wird nicht besser, weil während seiner Entwicklung mehr Commits gezählt wurden. Relevant ist eine andere Frage: Wie viel Prüfkapazität kann ein Projekt dieser Größe noch aufbringen, und wie geht es mit Beiträgen um, deren Ursprung schwer einzuschätzen ist?
Wer im Umfeld der Kernel-Entwicklung arbeitet, merkt die Folgen deutlicher. Die Commit-Zahl pro Merge Window ist von einem Nebenschauplatz zum Belastungsindikator geworden. Wer Patches einreicht, sollte mit längeren Warteschlangen rechnen; unklare Beiträge bleiben eher liegen. Saubere Begründungen, nachvollziehbare Tests und kleine, klar abgegrenzte Änderungen werden dadurch wichtiger, nicht unwichtiger.
Bleibt die Frage, die Larabel implizit stellt: Wie lange hält das Projekt das Tempo, ohne dass die Prüfseite kollabiert? Der Merge Window von Linux 7.4 ist der größte der Geschichte. Ob er ein Ausreißer bleibt oder der neue Normalwert wird, hängt nicht an der Zahl selbst, sondern daran, ob das Projekt einen Umgang mit ihr findet.
Quelle: phoronix.com
