Software::Entwicklung
Neue Diskussion über Kernel-Entwicklungsmodell
Kernel-Maintainer Andrew Morton hat seine Pläne zur Integration von Features in Kernel 2.6.19 vorgestellt, was zu einer erneuten Diskussion über das Kernel-Entwicklungsmodell führte.
Morton listete akribisch die hunderte von Patches auf, die er in seinen Entwicklerkernel integrieren will und von denen ein Großteil in der kommenden Kernelversion 2.6.19 erscheinen soll. Das Dateisystem Reiser4 wird wohl nicht dazugehören. Probleme im Kernel könnten zu einer Verschiebung der Reiser4-Integration auf Version 2.6.20 führen.
Eine Vorschlag von Jeff Garzik, weniger Features zu integrieren und dafür den Release-Zyklus neuer Versionen auf vier Wochen zu verkürzen, wurde ausführlich diskutiert. Zunächst erläuterte Andrew Morton, warum aus seiner Sicht die Zyklen mittlerweile deutlich länger als die ursprünglich angepeilten ein bis zwei Monate sind. Seit Kernel 2.6.11 besteht ein Release-Zyklus aus einer zweiwöchigen Phase, in der neue Features und Änderungen integriert werden. Diese endet mit der Veröffentlichung des ersten Release-Kandidaten der kommenden Version. Damit wird die Stabilisierungsphase eingeleitet, deren Dauer von den gefundenen Fehlern abhängt. In dieser Phase werden nur noch Fehler korrigiert.
Das Problem ist laut Morton, dass sich zuwenig Entwickler um die Fehlerbeseitigung kümmern. Stattdessen betrachten sie die Stabilisierungsphase als Zeitraum, in dem sie in aller Ruhe neue Features entwickeln können. In der Folge verlängern sich die Release-Zyklen und der Kernel enthält mehr Fehler. Würden mehr Leute sich auf die Fehler konzentrieren, würden die Release-Zyklen automatisch wieder kürzer.
Zu den diskutierten Ideen gehören die Konzentration von Änderungen auf bestimmte wechselnde Bereiche und die Einführung einer Unterscheidung zwischen geraden und ungeraden Revisionsnummern. So wäre beispielsweise 2.6.19 eine Version mit vielen Änderungen und entsprechend mehr zu erwarteten Fehlern, 2.6.20 eine Version mit sorgsam ausgewählten Korrekturen und sonst nichts. Die Versionen könnten dann im Abstand von etwa drei Wochen herauskommen. Linus Torvalds favorisiert dieses Modell, teilt aber die Bedenken von Morton, dass es letztlich nichts ändern würde.
Die Entwickler sind sich einig, dass schnellere Release-Zyklen zu weniger Fehlern führen. Ferner machen sie neue Features und Treiber den Anwendern schneller verfügbar. Um dies zu erreichen, müsste so mancher Entwickler aber daran »erinnert« werden, dass er endlich die gemeldeten Fehler in seinem Code beheben solle. Laut Andrew Morton will Google einen Entwickler einstellen, der genau das tun soll.
Eine Entscheidung über das zukünftige Vorgehen scheint noch nicht gefallen zu sein, doch aufgrund der breiten Zustimmung zu Torvalds' Vorschlag ist es durchaus möglich, dass Linus Torvalds mit der Freigabe von 2.6.19-rc1 eine neue Vorgehensweise bekannt gibt.
