Andrew Morton auf dem LinuxTag: Basar statt Kathedrale
Der Kernelmaintainer empfiehlt eine frühzeitige Integration neuen Codes in den Kernel und spricht sich gegen eine eigene Entwicklerkernelserie aus.
Linux-Kernel-Maintainer Anrew Morton beschrieb in seiner Keynote auf dem LinuxTag seine Ideen rund um Fragen der Kernelentwicklung. Dabei unterschied er in Anlehnung an Eric S. Raymonds bereits klassisches Essay zwischen zwei Arten der Entwicklung von neuen Kernelcodes. Bei der Basarmethode geben Entwickler nur wenig Code mit den Grundfunktionen neuer Features an die Maintainer. Mit jedem neuen Kernel-Release werden dann Verbesserungen und Erweiterungen in Zusammenarbeit mit der Kernel-Community realisiert. Bei der Kathedralenmethode (dem Sourceforge-Weg) findet die Entwicklung hingegen isoliert in eigenen Projekten statt. Den Kernel-Machern wird dann eine große Menge Code auf einmal zum Einbau in den Kernel präsentiert.
Das hat laut Morton zwei Nachteile: Das Testen großer Code-Mengen auf einmal kostet viel Zeit, und dafür findet man nur schwer geeignete Tester. Zum anderen sind oft Anpassungen an andere Kernel-Teile nötig, die sich in einem frühen Entwicklungsstadium viel leichter und schneller realisieren lassen. Als prominentes Beispiel für die Kathedralenmethode und ihre Probleme nannte der Kernelmaintainer das Dateisystem Reiser4, das bis heute nicht Teil des Standardkernels ist.
Laut Mortons Statistik ändern sich im Schnitt 9200 Zeilen Code pro Tag. Die "testing community" rund um den Kernel sei daher dessen wertvollstes Gut. Einem Entwicklerkernel 2.7, ähnlich wie ein Entwicklerkernel bis zum Erscheinen der aktuellen Version 2.6 parallel zum stabilen Kernel gepflegt wurde, erteilte Morton eine Absage. Wenn Codeerweiterungen zunächst in einen Entwicklerkernel flössen, wären diese Verbesserungen zu wenigen Nutzern zugänglich, da die meisten Linux-Anwender – und die Distributoren – bei den stabilen Kerneln blieben. Niemand wolle aber Code schreiben, der erst nach Monaten oder Jahren Anwender findet. So bleibt es beim jetzigen Verfahren, neue Features in einem Release Candidate zu testen und dann in einer stabilen Version zu veröffentlichen. (bbu/c't) / (odi)
