Linux: Kernel-Maintainer brauchen ein Manifest zum Arbeiten

Die Maintainer des Linux-Kernels werden immer stärker belastet. Ein Teil der Community versucht, das Problem aktiv zu lösen. Der Intel-Angestellte Daniel Vetter etwa schlägt dazu ein Manifest mit klaren Handlungsanweisungen vor, damit die Community künftig anders arbeitet.

Artikel veröffentlicht am 20. Januar 2017, 16:49 Uhr, Sebastian Grüner

Auf Veranstaltungen wie dem Kernel Summit diskutiert die Community in kleiner Runde ihre Probleme. (Bild: Linux Foundation, Flickr.com/CC-BY 2.0)

Um auf das steigende Wachstum des Linux-Kernels reagieren zu können, diskutiert die Entwickler-Community seit einigen Jahren, wie dies umgesetzt werden könnte. Denn soviel ist klar, ein Maintainer skaliert nicht, und dem Kernel fehlen Maintainer, also Verantwortliche für bestimmte Code-Bereiche. Der Intel-Angestellte Daniel Vetter hat auf der Linux-Conf-Au ein Manifest vorgeschlagen, das bei der Arbeit als Maintainer beachtet werden soll, und dies in seinem Blog zusammengefasst.

Vetter schreibt als Begründung hierfür: "Ich denke, was am Ende benötigt wird, sind einige Richtlinien und Diskussionen darüber, was ein Betreuer ist, und was ein Betreuer tut". Vetter, der seit Jahren am Linux-Grafikstack sowie dort an Intels Treiber arbeitet, begründet dies vor allem mit seinen persönlichen Erfahrungen als Betreuer.

Handreichung für neue und alte Maintainer

Notwendig sei das Manifest, weil der Posten des Betreuers standardmäßig durch Zufall vergeben werde, "und dann muss jeder auf eigene Faust lernen, wie man das tut, während man hoffentlich nicht zu viele Brücken hinter sich niederreißt - zumindest ich selbst war auf dieser Reise manchmal ziemlich verloren", schreibt Vetter.

Der Entwickler fordert etwa eine größere Akzeptanz für die Verantwortung des Postens, das heißt auch, nicht nur technische Entscheidungen fällen zu müssen und sich seiner eigenen Machtposition bewusst werden zu müssen, um diese nicht auszunutzen. Letztlich müssten die Betreuer auch ihre eigenen Grenzen kennen und danach handeln. Das heißt, etwa Arbeit abzugeben oder in letzter Konsequenz auch für Ersatz zu sorgen und die Arbeit ganz aufzugeben. Vor allem Letzteres ist in der Vergangenheit aber teilweise eben nicht umgesetzt worden, was zu einigen Problemen geführt hat.

Vetter selbst teilt sich seit einiger Zeit die Verantwortlichkeit für den Code mit seinem Team, was in einem starken Kontrast zu dem bisher sehr hierarchisch organisierten Betreuungsmodell des Linux-Kernels steht. Daraus ergibt sich laut Vetter ein weiterer Vorteil: "Zumindest für mich geht es nicht nur darum, eine gute Code-Qualität zu gewährleisten, sondern auch um die Verbreitung von Wissen und die Verbesserung des Verständnisses. Am Anfang gibt es vielleicht eine Person, die den Code versteht: den Autor (und selbst das ist nicht gegeben). Nach guter Überprüfung sollte es mindestens zwei Menschen geben, die den Code vollständig verstehen, einschließlich der Spezialfälle. Und das ist auch, warum ich denke, dass Gruppenbetreuung die einzige Möglichkeit ist, jedes Projekt mit mehr als einem Beitragenden zu führen."

Von der Umsetzung der Betreuergruppen ist die Kernel-Community für viele Codeteile aber trotz der anhaltenden Diskussionen darum noch weit entfernt.