Interview: "Debian ist traditionell stark im Server-Bereich"

Etch-Release-Manager Andreas Barth im Interview mit Golem.de

Für Debian 4.0 gaben die Entwickler der freien Linux-Distribution frühzeitig ein Veröffentlichungsdatum bekannt, welches dann doch um vier Monate verfehlt wurde. Neben diesem festen Termin als Ziel gab es im Etch-Veröffentlichungsprozess noch weitere Neuerungen. So führte Projektleiter Anthony Towns das Dunc-Tank ein, um die Release-Manager zu bezahlen. Nicht bei jedem Debian-Entwickler stieß diese Idee auf Begeisterung. Bereits Anfang Januar 2007 - nach der ersten Verschiebung von Etch - beantwortete Release-Manager Andreas Barth Golem.de einige Fragen zum Veröffentlichungsprozess, zum Verhältnis zu Ubuntu und Debians Marktposition.

Golem.de: Für Etch wurde erstmals ein fester Release-Termin bekannt gegeben, dennoch konnte dieser nicht eingehalten werden. Was waren die konkreten Gründe?

Andreas Barth: Naja, es gab auch früher schon Release-Termine. Für Etch haben wir nur sehr frühzeitig einen Termin bekannt gegeben und auch konsequent darauf hingearbeitet.

Die Verschiebung hat mehrere Gründe - insgesamt sind wir aber relativ gut hingekommen. Unser Hauptziel war, dass wir während des ganzen Release-Zyklus auch tatsächlich eine Veröffentlichung im Auge haben und darauf hinarbeiten. Das hat auch gut geklappt. Natürlich hätten wir gerne das genaue Datum eingehalten, aber Qualität war und ist uns wichtiger.

Ein anderer Grund waren auch unvorhersehbare Probleme, wie beispielsweise der Speicherfehler im Linux-Kernel. Auch andere haben deswegen ihre neue Version verschoben. Insgesamt hat die Planung wesentlich besser als für Sarge geklappt.

Golem.de: Inwiefern sind die Gründe auch innerhalb der Projektorganisation zu suchen?

Andreas Barth: Egal wie gut man organisiert ist, es gibt immer etwas, was man besser machen kann. Debian ist mit weit über 1.000 Aktiven ein relativ großes Projekt, da gibt es natürlich auch viele Verbesserungsoptionen. Natürlich sieht man immer wieder Probleme, aber insgesamt läuft es relativ gut. Das soll kein Plädoyer gegen Änderungen in der Projektorganisation sein, aber man muss sich auch darüber klar sein, dass es nie optimal gehen wird, und dass das Ergebnis trotz allem - über das man sich auch durchaus manchmal ärgert - ziemlich gut ist.