Linux-Kernel-Maintainer Andrew Morton zum Entwicklungsmodell

Die Zahlen sind beeindruckend: Ungefähr 4300 Zeilen Code kommen zum Kernel hinzu, 1800 löschen die Entwickler und 1500 erfahren Änderungen - pro Tag. Das sind die Durchschnittswerte für das Jahr 2007, wie Greg Kroah-Hartman auf einer Konferenz mit Kernelentwicklern mitteilte. Die Zahlen steigen durchschnittlich um zehn Prozent jährlich.

Damit die Menge der Änderungen überhaupt handhabbar bleibt, hat sich die Entwicklergemeinde eine ausgeklügelte Infrastruktur und ein hierarchisches Modell ausgedacht, um die Quellen des freien Betriebssystems effizient zu verwalten.

Die von vielen kleineren Projekten verwendeten Programme zur Versionskontrolle (VCS) waren Linus Torvalds dazu nicht genug. Gerade wenn es darum geht, gleichzeitig unterschiedliche Teile des Code abzuspalten, um dort weitreichende Veränderungen vorzunehmen und sie später wieder zusammenzuführen, stoßen die traditionellen VCS an Grenzen.

Dezentraler Code

Von 2002 bis 2005 wandte sich Torvalds darum erst dem proprietären Bitkeeper und später der freien Entwicklung Git zu, die mehr Komfort beim Verwalten von Varianten bieten. Git unterscheidet sich von anderen VCS darin, dass es kein zentrales Repository vorhält, sondern dezentrale Kopien des Code erlaubt. Es unterstützt den Austausch zwischen ihnen in Form von Patches. So lässt sich die Änderungshistorie großer Teile des Linux-Quelltextes seit der Einführung von Git im Frühjahr 2005 verfolgen.

Der komprimierte Quelltext des Kernels kommt als knapp 60 MByte großes Archiv daher und enthält rund sieben Millionen Zeilen Sourcecode. Da diese Menge nur schwer überschaubar ist, teilen die Entwickler sie in so genannte Subsysteme auf, die jeweils für eine eigenständige Funktionalität, ein bestimmtes Gerät oder eine Plattform zuständig sind. Aktuell betreuen rund 100 Maintainer knapp 300 Subsysteme vom Netzwerkstack bis hin zu kleinen Gerätetreibern.

Waren viele dieser Maintainer und Entwickler früher nichts als Enthusiasten, bezahlen heute viele Unternehmen sie dafür, diese Rolle einzunehmen, das unterstrich Andrew Morton auf der Konferenz. Bei der Qualitätssicherung und beim Berichten von Fehlern überwiegen jedoch die unbezahlten Freiwilligen.

Offizieller Kernel

Die meisten Maintainer setzen ebenfalls wie Morton und Torvalds Git ein. Die zentrale Frage für Entwickler und Maintainer lautet, wie der von ihnen geschriebene Code letztlich seinen Weg in die von Linus Torvalds gemanagten Versionen auf [http://kernel.org] findet.

Entwickler und Maintainer organisieren sich von Subsystem zu Subsystem individuell und testen ihren Code. Sie reichen die durchgeführten Änderungen in Form einer Serie von kleinen Änderungen (Patchsets) an Morton weiter. Der prüft, ob sich Konflikte mit anderen Subsystemen ergeben, und übernimmt die Patchsets schließlich in den von ihm betreuten »mm«-Tree in Git. Die Dauer dieses Prozesses schätzt Morton auf etwa zwei Monate (Abbildung 1).

Abbildung 1: Der Weg vom ersten Patch bis zur offiziellen Kernelrelease ist lang: Nachdem Entwickler Änderungen mit dem Maintainer abgestimmt haben, soll dieser ab sofort seine Patches in »linux-next« einreichen. Von dort gehen sie nach der Kontrolle durch Morton zu Linus Torvalds. Er nimmt sie innerhalb eines Patch-Window in die nächste Kernelversion auf.

Nachdem er eine als stabil gekennzeichnete Version 2.6.x veröffentlicht hat, öffnet Linus Torvalds ein so genanntes Merge Window. In dieser Zeit leitet Andrew Morton die gesammelten Änderungen an Torvalds weiter. Nach zwei Wochen schließt dieser das Fenster wieder und veröffentlicht die Version 2.6.x-rc1. Entwickler und Tester prüfen das Ergebnis und sorgen im Zwei-Wochen-Rhythmus für weitere Release Candidates. Ungefähr zwei Monate nach dem Öffnen des Merge Window ist die nächste stabile Version fertig und der Prozess wiederholt sich.

Die Linux-Entwickler betonen immer wieder die Vorzüge dieses Verfahrens gegenüber der früheren Parallelentwicklung von experimentellem und produktionsreifem Code: Anwender kämen so schneller in den Genuss eines ausführlich getesteten Kernels. Es habe sich gezeigt, dass Benutzer zu wenig motiviert sind, um experimentellen Code zu testen, erklärt Morton. Auch verweist er auf die Distributionshersteller, die eine weitere Stufe der Qualitätssicherung umsetzen, indem sie durch eigene Entwickler Patches pflegen und so aus der Technologie Linux ein Produkt machen.

Das Verfahren hat sich bewährt, es bedeutet aber eine Menge Aufwand für Morton. Da 85 Prozent der Änderungen ohnehin erfahrene Maintainer in den Kernel einreichen, plant Morton nun eine weitere Zwischeninstanz einzuführen. Er kündigte an, dass der Australier Stephen Rothwell künftig einen Git-Tree namens »linux-next« pflegen werde, in dem Rothwell schon getestete Änderungen aus bekannten Subsystemen zusammenführt.