Das Red-Hat-Modell: Auch Fedora denkt über andere Ausgabe-Zyklen nach – eventuell sogar über eine LTS-Variante
Heute geht es aber wild drunter und drüber … Ubuntu denkt laut über eine Art Rolling Releases nach, Alan Cox mag Fedora nicht mehr und auf der FUDcon wurde ebenfalls über einen andere Ausgabe-Zyklus von Fedora diskutiert.
Red Hats Máirín Duffy hat das Ganze in einem sehr langen Blog-Eintrag niedergeschrieben, was Tom “Spot” Callaway angesprochen hatte. Im Prinzip geht es darum, das Problem mit den Verzögerungen der Fedora-Ausgaben in den Griff zu bekommen. Verspätung gehört eigentlich zum guten Ton bei der von Red Hat gesponserten Linux-Distribution. Aber die fast 2,5 Monate bei Fedora 18 liegen wohl doch im Magen. Das komplette Neuschreiben von Anaconda hatte man sich einfacher vorgestellt, beziehungsweise hinterfragt man, ob sich so ein Brocken in 6 Monaten überhaupt verdauen lässt.
Per Standard mit GNOME 3.6 ...
12 Photos
KDE-Version von Fedora 18 ...
8 Photos
Längere Ausgabe-Zyklen würden das Problem aber auch nicht lösen. Würde man das Zeitfenster erhöhen, versuche man auch größere Brocken zu verschlingen und sollte man wie openSUSE auf einen 9-monatigen Zyklus gehen, käme die nächste Version erst nach 12 Monaten. Dadurch würde man nur andere Probleme schaffen.
Ein Rolling Release steht allerdings nicht zur Debatte. Viel mehr will man sich das alte Modell von Mutti Red Hat zum Vorbild nehmen. Beim Erscheinen von Red Hat 6.0 konnte man bei einer späteren Installation (zum Beispiel Red Hat 6.2) davon ausgehen, dass diese Punkt-Ausgabe mehr Feinschliff und mehr Funktionen beinhaltete. Eine .0-Version würde immer einen großen Schritt bedeuten. Wer immer auf dem aktuellen Stand sein wollte, ist auf 6.0 aufgesprungen. Konservativere Anwender haben Punkt-Versionen abgewartet.
Somit könnte man weiterhin alle 6 Monate eine neue Version zur Verfügung stellen und diese jeweils wieder 13 Monate mit Updates versorgen. Allerdings kaufe man sich damit mehr Zeit, eine Serie aufzupolieren. Aus Fedora 20 würde 20.0, nach 6 Monaten käme 20.1 und das Ganz führt man bis zu 20.3 fort. Alle zwei Jahre gibt es dann eine neue große Version. Somit hätte man den Anaconda-Brocken auf 4 Versionen verteilen können. Je höher die Zahl hinter dem Punkt, desto mehr Stabilität könne der Anwender erwarten.
Release-Modell (Quelle: blog.linuxgrrl.com)
Dazu gehöre aber auch, dass man dem Anwender Upgrades zur Verfügung stellen muss. Sobald Version 20.1 da ist, wird der Anwender benachrichtige und er kann ohne neu installieren zu müssen aktualisieren – wenn er das nicht möchte, kann er bei 20.0 verweilen.
Dann war da noch die Frage, die ich persönlich sehr spannend fand: Einige Anwender wollen doch sicher nur immer die x.3-Version verwenden und auf eine nächste x.3 warten. Wie machen wir da eine Unterstützung möglich?
Die Antwort war, dass man darauf eine Antwort geben könne, wenn es so weit ist. Wenn bei den Anwendern der Wunsch nach LTS (Langzeitunterstützung / Long Term Support) besteht, könne man darüber reden. Verprechen wollte Callaway das nicht. Aber er sagte auch, dass man über längere Support-Fristen, zum Beispiel 18 Monate, sprechen könnte.
Lassen wir uns überraschen. Es fühlt sich auf jeden Fall so an, dass etwas geändert werden sollte. Alleine der Fakt, dass mich das System über die Verfügbarkeit einer neuen Punkt-Version benachrichtigt und ich kann dann aktualisieren, würde Fedora für mich schon wieder so viel attraktiver machen … den Plan finde ich nicht schlecht. Eine LTS-Variante wäre ein Traum … 🙂
Fedora bleibt attraktiv, obwohl der letzte Upgradevorgang schwieriger als zuvor war. Das verzögerte Erscheinen einer Version ist mir schnuppe. Mir reichte alle sechs Monate + Verspätung eine ausgereifte Version. Also nicht das, was mit F 18, sondern das, was mit F 16 und 17 abgeliefert worden ist.