Am Mittwoch, 20. Januar 2016, 15:01:17 CET schrieb Jan-Tarek Butt via Dev:
Wie seht ihr das? Wie wollen wir vor gehen?
Hi,
ich habe dazu eine sehr harte und unangenehme Meinung: 1. der testing Zweig der Firmware wird nicht supportet. 2. das Mischen von stable und testing ist eine absolute No-Go-Area. 3. stehen komplizierte Entwicklungen an, wird immer nur ein Entwicklungsschritt gleichzeitig gegangen. Sprich in diesem Fall wird die Netzstruktur ODER Gluon geupdated, aber nicht beides gleichzeitig.
Ich will das auch gerne begründen.
Zu Punkt 1: Wenn wir den testing Zweig wie einen stable Zweig supporten, nehmen wir uns die Möglichkeit den Zweig dazu zu nutzen, wozu er gedacht ist: zum Testen. Wir erhalten dann einfach zwei stable Zweige. Das ergibt aber zum einen überhaupt keinen Sinn und verursacht zum anderen auch noch doppelte Arbeit, die niemand leisten kann. Jeder der sich einen testing Zweig installiert muss sich darüber im klaren sein, dass sein Router mittelfristig unbrauchbar wird oder regelmäßig neu geflasht werden muss.
Zu Punkt 2: Dass eine Schnittmenge aus stable und testing keine stabile Firmware ergibt, brauche ich wahrscheinlich niemandem erklären. Wenn man Milch und Kakao zusammenschüttet, ist das Ergebnis auch nicht Milch sondern irgendetwas zwischen Kakao und Milch. Andere Stoffe reagieren sogar miteinander und haben schlimme Dinge zum Ergebnis.
Was ich damit sagen will ist, dass das Aufsetzen einer stabilen Gluon 2015.x Konfiguration auf einen instabilen Gluon 2016.x Unterbau mit Sicherheit alles mögliche ergibt, aber keine stabile Firmware. Und Falls doch, dann wäre das unverschämtes Glück. Dass ein (Software-)Ingenieur sich aufs Glück verlässt habe ich aber noch nie gehört.
Für Benutzer gilt das übrigens ebenso. Niemals sollte ein Benutzer eine testing Firmware benutzen aber Updates aus dem stable Zweig beziehen. Sonst reagieren diese beiden Zweige nämlich sehr unangenehm miteinander. Im aktuellen Fall wird das bei einem Update des stable Zweiges mit einer Gluon 2015.x Firmware dazu führen, dass mindestens 40 Router sofort ihren Dienst versagen. Denn es gibt aktuell ca. 40 WR841NDv10, bei denen die Benutzer sowohl Punkt 1 als auch Punkt 2 sehr gekonnt ignoriert haben.
Zu Punkt 3: Einen komplizierten Schritt pro Update zu gehen hat den einfachen Grund, dass man Fehler sonst nicht eingrenzen kann.
Jedes größere Update bringt Fehler mit. Und in den sechs Jahren in denen ich jetzt hier mitarbeite habe ich gelernt, dass es von diesem Gesetz keine Ausnahmen gibt. Beim nächsten Update werden Fehler auftreten, die wir nicht vorhergesehen haben.
Das ist aber nicht weiter schlimm, denn Fehler kann man beheben. Problematisch wird es immer erst dann, wenn sich Fehler nicht eingrenzen lassen, weil man verschiedene komplizierte Änderungen gleichzeitig durchgeführt hat. Updatet man bspw. die Netzstruktur und den Gluon Unterbau gleichzeitig, kann niemand sagen ob ein Fehlerhafter Router jetzt offline ist wegen dem Netzupdate oder wegen dem Update von Gluon. Das ist ein Zustand den keiner will und darum wird nur eine komplizierte Änderung pro Version durchgeführt.
Beachtet man diese Regeln, ergeben sich zwei mögliche Entwicklungspfade:
Pfad 1: Version 0.7: Auslieferung des Hoodselectors Version 0.7.1: Aktivierung der ersten Hood Version 0.7.x: Bugfixing der neuen Netzstruktur Version 0.8: Update auf Gluon 2016.1 Version 0.8.x: Bugfixing von Gluon 2016.1
Pfad 2: Version 0.7: Update auf Gluon 2016.1 Version 0.7.x: Bugfixing von Gluon 2016.1 Version 0.8: Auslieferung des Hoodselectors Version 0.8.1: Aktivierung der ersten Hood Version 0.8.x: Bugfixing der neuen Netzstruktur
Ich persönlich würde Pfad 1 präferieren, denn die Bugs für Gluon 2016.1 sehen nicht danach aus, als würden sie schnell gefixed: https://github.com/freifunk-gluon/gluon/issues?q=is%3Aopen+is%3Aissue +milestone%3A2016.1
In jedem Fall sollten wir aber alle Personen, die eine testing Firmware einsetzen und trotzdem den stable Zweig im Autoupdater eingestellt haben, auffordern ihren Update-Zweig zurück auf testing zu setzen und sie darauf hinweisen, dass die testing Firmware nicht supportet wird. Sonst ist das Gejammer nachher groß und wir sind Schuld, weil wir niemanden gewarnt haben.
LG Clemens