Linux-Entwickler: Kernel-Community wird unter eigener Bürokratie zusammenbrechen
Die Maintainer des Linux-Kernels werden in ein paar Jahren nicht mehr nachkommen, eingereichte Patches zu bearbeiten. Das System stehe vor dem Kollaps, falls sie es nicht schafften, die Arbeitslast zu verteilen, behauptet Kernel-Entwickler Daniel Vetter.
(Bild: Pixabay)
Am Linux-Kernel kann jeder mitarbeiten, den eigentlichen Quellcode anfassen darf allerdings nur eine Gruppe von privilegierten Entwicklern. Diese sogenannten Maintainer sollen dafür sorgen, dass Patches und neue Funktionen, die im Kernel landen, die gewohnte Qualität erfüllen. Das System funktioniert allerdings nicht so gut wie oft beworben, behauptet Kernel-Entwickler Daniel Vetter. Er verweist dabei darauf, dass Maintainer immer weniger eigenen Code einpflegen und stattdessen seiner Ansicht nach zu einem bürokratischen Flaschenhals werden. Außerdem will er beobachtet haben, dass die Patches der Maintainer nicht so genau geprüft werden wie die der normalen Entwickler.
Vetter, selbst Maintainer des Intel-i915-Grafiktreibers im Linux-Kernel, hat Pull-Requests im Kernel analysiert, um zu seinen Erkenntnissen zu kommen. Wie er selbst zugibt, ermöglicht das nur einen Blick auf die Subsystem-Ebene des Kernels mit ihren verschiedenen Maintainern, nicht aber auf einzelne Patches. Genau diese Subsystem-Ebene interessiert ihn allerdings hauptsächlich und er macht kräftig Werbung dafür, wie er und seine Kollegen im Grafik-Subsystem die Situation der Maintainer verbessert haben. Er empfiehlt anderen Maintainern, dem Wachstum des Kernel-Umfangs damit zu begegnen, Junior-Maintainer auszubilden und die Arbeit auf mehr Schultern zu verteilen.
Bürokratie-Apokalypse
Ändert sich die aktuelle Herangehensweise an die steigenden Belastungen der Kernel-Entwicklung nicht, droht laut Vetter dem Linux-Kernel der Zusammenbruch. Von Maintainern wird erwartet, dass sie den Quellcode ihrer Kollegen prüfen, bevor sie ihn an Linus Torvalds und den ihn umgebenden Kreis aus Maintainern übergeben. Deswegen haben nur sie Commit-Rechte für das Quellcode-Repository. Diese Infrastruktur stellt eine gewisse Qualitätskontrolle sicher und sorgt dafür, dass Torvalds immer weiß, welchen Subsystem-Maintainer er anschreien kann, wenn der Code seinen Ansprüchen nicht gerecht wird.
"Naively extrapolating the relative trend predicts that around the year 2025 large numbers of kernel maintainers will do nothing else than be the bottleneck, preventing everyone else from getting their work merged and not contributing anything of their own. The kernel community imploding under its own bureaucratic weight being the likely outcome of that."
- Daniel Vetter
Da der Kernel aber immer größer und komplexer wird, sind Maintainer Vetters Statistiken zufolge immer öfter damit beschäftigt, die Patches anderer Entwickler durchzuwinken. Sie verbringen deswegen immer weniger Zeit damit, eigenen Code zu schreiben. Das ist auch deswegen bedenklich, da Subsystem-Maintainer oft in der Hierarchie der Kernel-Entwickler aufgestiegen sind, weil sie die besten ihres Fachs sind. Um Vetters Analyse zu zuspitzen: Je weniger die Maintainer selbst entwickeln, desto mehr guter Code geht dem Kernel durch die Lappen.
Seiner nach eigenen Angaben "naiven Schätzung" nach werden im Jahr 2025 die meisten Maintainer nur noch damit beschäftigt sein, Patches abzusegnen. Das werde einen Flaschenhals in der Kernel-Gemeinde verursachen, diese könne letztlich unter dem Gewicht der eigenen Bürokratie zusammenbrechen. Das stehe in starkem Kontrast zum Mantra, beim Kernel werde alles immer größer und besser und die Community sei kerngesund, dem er immer wieder auf Konferenzen und in Berichten der Kernel-Entwickler begegne.
Doppelte Standards
Aber Vetter hat noch einen weiteren beunruhigenden Trend ausgemacht: Die Patches der Maintainer werden seiner Analyse nach nicht so genau geprüft wie die der normalen Entwickler ohne Commit-Rechte. Seiner Meinung nach wenden Maintainer oft doppelte Standards an: Während sie die Patches anderer anschauen, landen ihre eigenen Patches oft im Quellcode, ohne von einem Kollegen geprüft worden zu sein.
Als Negativbeispiel führt er das Netzwerk-Subsystem an: Hier würden momentan überhaupt nur 9 Prozent der Commits von einem zweiten Entwickler auf Subsystem-Ebene geprüft. In seinem eigenen Subsystem für Grafiktreiber läge diese Zahl bei 83 Prozent. Bei kleineren Subsystemen und auf den ganzen Kernel bezogen sehe die Situation allerdings besser aus. Viele Maintainer gäben sich Mühe, ihre Arbeit von Kollegen prüfen zu lassen, bevor sie den Code einreichen und außerdem steige der Prozentsatz der Code-Reviews im Kernel generell.
Grundsätzlich sei es keine schwarze Magie, für entsprechende Code Reviews und Prüfungen zu sorgen. Die Lösung sei die selbe wie die, um den Maintainer-Flaschenhals zu vermeiden, meint Vetter: Die Subsystem-Verantwortlichen müssten dafür sorgen, dass sie die Arbeit verteilen und geeignete Entwickler rekrutieren und als Maintainer ausbilden. Das führe dann nicht nur dazu, dass alle mehr eigenen Code schreiben könnten, sondern schaffe auch Ressourcen, um den Code der anderen gegenzuchecken. (fab)
