Kritik an Linux Kernel Mailingliste: Workflow als Hürde für neue Entwickler?

Inhaltsverzeichnis

Sarah Novotny, Board-Mitglied der Linux Foundation und bei Microsoft Azure zuständig für Open-Source-Fragen, schlägt eine Änderung der Arbeitsabläufe und der genutzten Tools der Linux Kernel Mailingliste (LKML) vor. Dadurch will sie die Rolle des Kernel-Maintainers attraktiver gerade für jüngere Entwickler machen. Diese könnten mit der Arbeitsweise der LKML heute oft nur noch so wenig anfangen, dass es zu einer echten Einstiegshürde werde, meint Novotny.

Maintainer-Knappheit

Zwar tritt als Gesicht der Linux-Entwicklung nach außen hin fast immer nur Linux-Erfinder Linus Torvalds in den Vordergrund. Hinter den Kulissen hat Torvalds aber schon seit Jahrzehnten ein Team von "Subsystem-Maintainern" um sich geschart, die die Entwicklung einzelner Teilbereiche des Kernels übernehmen.

Jens Axboe etwa zeichnet als Maintainer des Blockgeräte-Subsystems für all jene Treiber im Kernel verantwortlich, die sich mit Festplatten, SSDs und ähnlichen Geräten beschäftigen. Das Problem: Der Kernel selbst wird immer größer, weil er immer mehr Funktionen übernimmt. Neue Subsystem-Maintainer finden sich aber nicht so leicht, sodass die Mehrarbeit auf die immer gleiche Anzahl von Schultern verteilt wird.

Klassischerweise wird ein Entwickler Maintainer im Kernel-Team, wenn er über einen längeren Zeitraum regelmäßig Patches für einen Teilbereich von Linux beigesteuert und verwaltet hat. Indes ist die Zahl der jüngeren Linux-Entwickler, die am Kernel mitarbeiten, in den vergangenen Jahren kontinuierlich gesunken. Einige der heutigen Subsystem-Maintainer sind noch Teil der "ersten Garde" und zum Teil seit über 20 Jahren im Geschäft.

LKML als Hemmschuh

Diesen Umstand führt Sarah Novotny im Interview mit The Register nun darauf zurück, dass die Arbeitsabläufe der Linux Kernel Mailingliste gerade für junge Entwickler künstliche Hürden schafften. Sämtliche relevante Kommunikation während der Linux-Entwicklung findet bis heute auf der LKML statt, das zentrale Arbeitswerkzeug ist also der eigene Mail-Client der Entwickler. Wer die Arbeit mit Issue-Trackern in Tools wie GitHub oder GitLab gewohnt sei, tue sich schon mit diesem Umstand schwer.

Hinzu kämen laut Novotny viele Regeln für das Format von E-Mails, die gerade die Altvorderen der Linux-Entwicklung vehement verteidigen: Schreibt man etwa eine Mail an die LKML im HTML-Format, was bei den meisten Mail-Programmen heute schon lange Standard ist, kann man durchaus den Hinweis bekommen, gefälligst Reintext-Mails zu senden. Mails, die sich nicht an zum Teil 25 Jahre alte Regeln halten, werden von manchem Entwickler auch ganz einfach ignoriert. Das hilft zwar womöglich, das Verständnis von Ordnung der bestehenden Maintainer zu befriedigen, könnte aber auf neue Entwickler auch abschreckend wirken.

Patch-Verarbeitung per Mail

Ebenso ungewohnt ist in Novotnys Sicht die Verarbeitung von Patches aus E-Mails heraus. Die Subsystem-Maintainer etwa kündigen ihre Patches für neue Kernel-Releases stets mit einer E-Mail an, die eine Zusammenfassung enthält, gefolgt von manchmal hunderten Mails mit den angehängten Einzelpatches. Meldungen auf der Mailingliste über neue Kernel-Releases von Linus Torvalds oder den Maintainern der LTS-Kernels enthalten stets die Liste der eingepflegten Git-Commits. Diese Herangehensweise mache es für junge Entwickler extrem schwierig, sich auch nur einen Überblick zu verschaffen.

Zumal die LKML hier eher als eine Art öffentliches Tracking System zum Einsatz kommt: Der Austausch von Patches selbst passiert heute beinahe ausschließlich über Git-Pull-Requests im Hintergrund. Die Mails auf der LKML dokumentieren diese lediglich – ein Blick in die Git-Historie würde allerdings ebenso Aufschluss geben.

Novotny schlägt Alternative vor

Sarah Novotny schlägt deshalb vor, die vorhandenen Arbeitsabläufe zu ändern oder zu ergänzen. Das soll spezifisch Software-Entwickler ansprechen, die ihre Sozialisation in den vergangenen zehn bis 15 Jahren erhalten haben. Sonderlich konkret wird Novotny in ihren Vorschlägen allerdings nicht. Ein Ansatz, so Novotny, könnte deshalb darin bestehen, die LKML um einen Arbeitsmodus zu erweitern, der wie ein Issue-Tracker funktioniert.

Die Arbeit per Mail, so wie Entwickler sie von der LKML aktuell gewohnt sind, könne dabei ohne Probleme erhalten bleiben. Jüngere Entwickler könnten ihre Beiträge aber über andere Wege einreichen, die eher ihrer Gewohnheit entsprechen, zum Beispiel über direkte Git-Pull-Requests. Ein entsprechendes Tool im Hintergrund könnte aus diesen noch immer völlig automatisch Mails für die LKML generieren.

Ein radikalerer Ansatz wäre freilich, bei Patches auf die LKML zu verzichten und bloß noch Git zu verwenden. Diskussionen über technische Details könnten dann auf der LKML stattfinden, Patches wären aber bloß noch in Git zu sehen. (axk)