Login
Login-Name Passwort


 
Newsletter
Werbung

Mi, 9. August 2017, 15:15

Software::Kernel

Vetter: Warum Github nicht für die Kernel-Entwicklung geeignet ist

Warum findet die Linux-Kernel-Entwicklung nicht auf Github oder ähnlichen webbasierten Systemen statt? Der Grund ist, dass solche Systeme nicht die etablierten und bewährten Arbeitsabläufe der Kernel-Entwicklung abbilden können, wie Kernel-Entwickler Daniel Vetter in einem langen Aufsatz erläutert.

Larry Ewing

Als Linus Torvalds im Jahr 2005 Git als neue Versionsverwaltung konzipierte, war das System eigentlich nur für die Bedürfnisse der Kernel-Entwicklung gedacht. Doch Git wurde schnell zu einem riesigen Erfolg und wird nun von zahlreichen Projekten eingesetzt, nicht nur in der freien Software-Welt. Webdienste, die auf Git aufsetzen, wie Github und GitLab, haben Millionen von Benutzern und Projekten. Diese Dienste machen den Umgang mit Git für viele Leute erheblich einfacher und bieten gleich noch Mittel zur Kommunikation an, wozu auch Fehlerverwaltung und ähnliches zählen. Projekte auf Github arbeiten mit Pull Requests, um Änderungen aufzunehmen.

Der Linux-Kernel ist ein sehr großes Projekt, doch es gibt noch größere. Alle diese Projekte haben laut Vetter erkannt, dass auch Git nicht unendlich skaliert. Pull Requests und die Fehlerverwaltung auf Github werden unhandlich, wenn die Projekte zu groß werden. Die Lösung ist, das Projekt in mehrere Unter-Repositorien aufzuteilen. Das löst, wie Kernel-Entwickler Daniel Vetter in einem langen Artikel schreibt, die Probleme und funktioniert gut. Doch es hat auch Nachteile. So wird das Projekt fragmentiert, da viele Entwickler nur noch das Repositorium ansehen, das sie benötigen. Die Verwaltung der Repositorien wird kompliziert, Lösungen werden unter Umständen mehrfach implementiert, und es wird schwer, den Überblick über das Gesamtprojekt zu behalten und Änderungen zu koordinieren, wenn es nötig ist.

Der Linux-Kernel skaliert auf ganz andere Weise. Auf den ersten Blick sieht es so aus, als sei alles in einem einzelnen Repositorium enthalten, einem Monorepo, wie Vetter es nennt. Doch niemand außer Torvalds selbst, der das offizielle Repositorium besitzt, entwickelt direkt auf diesem. Stattdessen pflegen zahlreiche Entwickler, Distributionen, Hardware-Hersteller und Leiter der verschiedenen Teilsysteme des Kernels eigene Repositorien. Zwar haben diese alle eine gemeinsame Basis, sie können sich aber stark auseinanderentwickeln. Änderungen werden als Patch-Dateien per E-Mail an eine oder mehrere der Entwicklungslisten verteilt und in eines oder mehrere Repositorien übernommen. Dann werden sie in komplexer Weise zu anderen Repositorien weitergereicht, üblicherweise immer nur in eine Richtung. Weltweit gibt es sicher tausende von Repositorien.

Laut Vetter könnte man nur mit großer Mühe diese Abläufe mit Github nachbilden, wobei man auf jeden Fall die komfortable Oberfläche verlassen und mit der Kommandozeile und mit Patches und Pull Requests per E-Mail arbeiten müsste. Github müsste nur eine einzige Funktionalität implementieren, um diesem Mangel abzuhelfen: Pull Requests und Bugtracker sollten über verschiedene Klone eines Projekts hinweg möglich sein. Es müsste außerdem möglich sein, mehrere Forks eines Repositoriums innerhalb einer einzigen Organisation anlegen zu können. Dies ist vollständig orthogonal zu den Zweigen, von denen jedes Repositorium beliebig viele haben kann, unabhängig von allen anderen.

Der Linux-Kernel wird sicher nie seine Entwicklung zu Github verlagern, selbst wenn die derzeitige technische Hürde wegfallen sollte. Ein wichtiger Grund dafür ist, dass viele der Top-Entwickler klar gegen einen solchen Schritt sind. Aber die Abbildung der Kernel-Entwicklungsmethode auf Github wäre auch für viele andere Projekte von Nutzen, meint Vetter.

Werbung
Pro-Linux
Traut euch!
Neue Nachrichten
Werbung