Nächste Firmware Version
Hi zusammen, Wie wollen wir das nächste Release angehen. Wir haben bereits einige wr841v10 im Einsatz die auf der Testing Firmware laufen. Der Autoupdater läuft bei den Routern auf Stable so das die Router auf eine Firmware > 0.7 warten. Zudem haben wir das Problem das die v10 erst mit gluon v2016.1 supported werden. Mein Vorschlag wäre wir bauen 0.7 mit der Basis v2015.x und die v10 bleiben weiter in testing somit werden diese erst gegen Mitte Februar in Stable kommen. Es gab ein Vorschlag die v10 aus testing in stable zu übernehmen und das reguläre stable auf Basis von v2015.x zu belassen. Allerding fände ich eine Mischung von testing uns stable unschön. Wie seht ihr das? Wie wollen wir vor gehen?
Hi, ich denke wir sollten die v10 weiterhin auf stable lassen und hier einfach für den 841er testing Images anbieten. Das Mischen einer Firmware wäre wahrscheinlich das schlimmste, was wir machen können. Viele Grüße, Stefan Am 20.01.2016 um 15:01 schrieb Jan-Tarek Butt via Dev:
Hi zusammen,
Wie wollen wir das nächste Release angehen. Wir haben bereits einige wr841v10 im Einsatz die auf der Testing Firmware laufen. Der Autoupdater läuft bei den Routern auf Stable so das die Router auf eine Firmware > 0.7 warten.
Zudem haben wir das Problem das die v10 erst mit gluon v2016.1 supported werden. Mein Vorschlag wäre wir bauen 0.7 mit der Basis v2015.x und die v10 bleiben weiter in testing somit werden diese erst gegen Mitte Februar in Stable kommen.
Es gab ein Vorschlag die v10 aus testing in stable zu übernehmen und das reguläre stable auf Basis von v2015.x zu belassen. Allerding fände ich eine Mischung von testing uns stable unschön.
Wie seht ihr das? Wie wollen wir vor gehen?
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Ich denke eine zeitlich und gerätespezifische klar eingegrenzte Mischung von testing und stable ist um ein vielfaches besser, als diejenigen v10 Geräte, die bereits online sind, zu verlieren, indem sie notwendige Updates verpassen. Zeitlich eingeschränkt bis zum gluon-release. Es betrifft nur die v10 Geräte. Ich denke über einen Monat können wir diese Mischung ertragen. Die Alternative ist Endusern auf die Nerven zu gehen, was, wie ich finde, keine Alternative ist. Wir dürfen dabei nicht vergessen, dass inzwischen vielfach Menschen mit Freifunk versorgt werden, die nicht den Luxus genießen, ständig auf eine funktionierende Alternative wechseln zu können. Im Sinne einer „Risikoabschätzung“ ist meine Entscheidung klar! Ein Update muss meiner Meinung auch erst ausgerollt werden, wenn die Serverinfrastruktur bereit für den Netsplit ist. Evtl. erübrigt sich diese Entscheidung, wenn das gluon-release früher fertig ist. -- Viele Grüße, Simon
Hi,
Ich denke eine zeitlich und gerätespezifische klar eingegrenzte Mischung von testing und stable ist um ein vielfaches besser, als diejenigen v10 Geräte, die bereits online sind, zu verlieren, indem sie notwendige Updates verpassen.
Zeitlich eingeschränkt bis zum gluon-release. Es betrifft nur die v10 Geräte.
Ich denke über einen Monat können wir diese Mischung ertragen. Die Alternative ist Endusern auf die Nerven zu gehen, was, wie ich finde, keine Alternative ist.
Wir dürfen dabei nicht vergessen, dass inzwischen vielfach Menschen mit Freifunk versorgt werden, die nicht den Luxus genießen, ständig auf eine funktionierende Alternative wechseln zu können.
Im Sinne einer „Risikoabschätzung“ ist meine Entscheidung klar!
Ich stimme dir zu. Allerdings muss nach außen detailliert und gut kommuniziert werden das es sein kann, das die testing Router z.B. nach einem update gebrickt sein könnten oder sonst was! D.h. die Nächste Firmware sollte 0.7.1 werden dass sollte dann auf basis v2015.x sein und dann noch eine 0.7.1 testing mit verwies auf stable die auf basis vom Master ist.
Ein Update muss meiner Meinung auch erst ausgerollt werden, wenn die Serverinfrastruktur bereit für den Netsplit ist. Evtl. erübrigt sich diese Entscheidung, wenn das gluon-release früher fertig ist.
Das ist nicht ganz richtig alle Router sollten bereits den hoodselector haben bevor die erste wirklich hood eingerichtet wird. Somit wird verhindert das Router nicht mehr online kommen können da diese nicht die bssid einer nachbarhood übernehmen. vg Tarek
On 20.01.2016 21:13, Jan-Tarek Butt via Dev wrote:
Ich stimme dir zu. Danke! :D Allerdings muss nach außen detailliert und gut kommuniziert werden das es sein kann, das die testing Router z.B. nach einem update gebrickt sein könnten oder sonst was!
D.h. die Nächste Firmware sollte 0.7.1 werden dass sollte dann auf basis v2015.x sein und dann noch eine 0.7.1 testing mit verwies auf stable die auf basis vom Master ist. JA! Oder das Problem löst sich in Wohlgefallen auf (s.u.)
Ein Update muss meiner Meinung auch erst ausgerollt werden, wenn die Serverinfrastruktur bereit für den Netsplit ist. Evtl. erübrigt sich diese Entscheidung, wenn das gluon-release früher fertig ist. Das ist nicht ganz richtig alle Router sollten bereits den hoodselector haben bevor die erste wirklich hood eingerichtet wird. Somit wird verhindert das Router nicht mehr online kommen können da diese nicht die bssid einer nachbarhood übernehmen.
Das war anders gemeint. Der hoodselector muss erst ausgerollt werden, wenn die Server instantan umgestellt werden können (nicht worden sind). Evtl. erübrigt sich dieses Problem, da wir schon bald Februar haben. Das hängt natürlich davon ab, was schneller da ist: 2016.1 oder eine fertige puppet-Infra. -- Viele Grüße, Simon
On 01/20/16 22:01, Simon Kurka wrote:
On 20.01.2016 21:13, Jan-Tarek Butt via Dev wrote:
Ich stimme dir zu. Danke! :D
:P Das ist ja nur meine Meinung :D Die Mehrheit hat das ja letztlich zu entscheiden.
Allerdings muss nach außen detailliert und gut kommuniziert werden das es sein kann, das die testing Router z.B. nach einem update gebrickt sein könnten oder sonst was!
D.h. die Nächste Firmware sollte 0.7.1 werden dass sollte dann auf basis v2015.x sein und dann noch eine 0.7.1 testing mit verwies auf stable die auf basis vom Master ist. JA! Oder das Problem löst sich in Wohlgefallen auf (s.u.)
Ein Update muss meiner Meinung auch erst ausgerollt werden, wenn die Serverinfrastruktur bereit für den Netsplit ist. Evtl. erübrigt sich diese Entscheidung, wenn das gluon-release früher fertig ist. Das ist nicht ganz richtig alle Router sollten bereits den hoodselector haben bevor die erste wirklich hood eingerichtet wird. Somit wird verhindert das Router nicht mehr online kommen können da diese nicht die bssid einer nachbarhood übernehmen.
Das war anders gemeint. Der hoodselector muss erst ausgerollt werden, wenn die Server instantan umgestellt werden können (nicht worden sind). Evtl. erübrigt sich dieses Problem, da wir schon bald Februar haben. Das hängt natürlich davon ab, was schneller da ist: 2016.1 oder eine fertige puppet-Infra.
Mein Stand war das wir bereits hoods ausrollen könnten die nur über Berlin angebunden sind. Damit könnten wir z.B. Wittmund in eine Hood auslagern. Somit könnten wir das Netz näher in einen funktionierenden zustand bringen. vg Tarek
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
Ich kann diese grundsätzlich ablehnende Haltung bzgl. der Software für die v10 Geräte nicht nachvollziehen. Eine Mischung von stable und testing ist hässlich, das ist mir klar. Uns treffen blöderweise Einflüsse von außen (hier TP-Link). Man kommt quasi nicht mehr an v9 Geräte ran, das ist ein Fakt! Man kann nun natürlich auf seine Strukturen bestehen und damit möglichen Fortschritt aufhalten. Genau das können Menschen, die nicht voll im Thema sind, nicht nachvollziehen und es hinterlässt den nachhaltigsten Schaden der überhaupt entstehen kann: In den Köpfen der Menschen. Ich denke es muss grundsätzlich darum gehen, Lösungen zu Problemen zu finden. Natürlich muss man dabei aufpassen, dass man nicht im strukturlosen Chaos endet, keine Frage! Die „Mischung“ von stable und testing ist räumlich und zeitlich beschränkt. Die v10-Geräte können evtl. ein Suffix „-testing“ bekommen um das Problem deutlich zu machen. Die testing ist momentan die einzig mögliche Lösung für die v10 Geräte, die, nicht nur von mir, propagiert wird. Den ahnungslosen Endnutzern, die verzweifelt versuchen, ihren stolz erstandenen Freifunk-Router in Betrieb zu nehmen, jetzt die Schuld zuzuweisen, dass der stable-branch im Autoupdater eingestellt ist, war hoffentlich ein versehen. Diese Funktion ist bewusst direkt in die entsprechende Firmware eingebaut, um die zeitliche Beschränkung dieser (unschönen, aber einzig möglichen) Lösung sicher zu stellen. Der Benutzer hat da nichts zu getan! btw Pfad 1 ist böse. Die v10 Geräte aktualisieren in Schritt 2 auf Version 0.7.1 (Aktivierung der ersten Hood), ohne dass sie mit einem Hood-dasein umgehen könnten (hoodselector nicht ausgeliefert). Ich denke wir sollten aufhören die Problematik mit den v10 Geräten als Mischung zu sehen. Eine Mischung tritt nur mit der manuellen Platzierung in einem Verzeichnis und einem Manifest auf. Ansonsten sind es schlicht zwei Entwicklungszweige, die aktuell parallel gepflegt werden müssen (mit zeitlicher Beschränkung!). -- Viele Grüße, Simon
Hi,
Ich kann diese grundsätzlich ablehnende Haltung bzgl. der Software für die v10 Geräte nicht nachvollziehen.
Eine Mischung von stable und testing ist hässlich, das ist mir klar. Uns treffen blöderweise Einflüsse von außen (hier TP-Link). Man kommt quasi nicht mehr an v9 Geräte ran, das ist ein Fakt!
Leider Ja...
Genau das können Menschen, die nicht voll im Thema sind, nicht nachvollziehen und es hinterlässt den nachhaltigsten Schaden der überhaupt entstehen kann: In den Köpfen der Menschen.
Das ist leider ein großes Problem das viele Menschen solche komplexen Strukturen zu einfach betrachten. Das wäre im Grunde das selbe Thema wie das Freifunk kein HOTSPOT Anbieter im klassischem sinne ist. Sondern eben ein Freies Netzwerk.
Ich denke es muss grundsätzlich darum gehen, Lösungen zu Problemen zu finden. Natürlich muss man dabei aufpassen, dass man nicht im strukturlosen Chaos endet, keine Frage! Die „Mischung“ von stable und testing ist räumlich und zeitlich beschränkt. Die v10-Geräte können evtl. ein Suffix „-testing“ bekommen um das Problem deutlich zu machen.
Was spricht dann dagegen diese einfach weiterhin in testing zu belassen ? Der branch testing könnte man ja wie das Suffix „-testing“ betrachten?
Die testing ist momentan die einzig mögliche Lösung für die v10 Geräte, die, nicht nur von mir, propagiert wird. Den ahnungslosen Endnutzern, die verzweifelt versuchen, ihren stolz erstandenen Freifunk-Router in Betrieb zu nehmen, jetzt die Schuld zuzuweisen, dass der stable-branch im Autoupdater eingestellt ist, war hoffentlich ein versehen.
Ich glaube das ist missverstanden. Es geht hier nicht um schuld Zuweisungen sondern eher um die Bewusstheit das die Router die als testing betrieben werden eben unerahnte Probleme erzeugen können.
btw Pfad 1 ist böse. Die v10 Geräte aktualisieren in Schritt 2 auf Version 0.7.1 (Aktivierung der ersten Hood), ohne dass sie mit einem Hood-dasein umgehen könnten (hoodselector nicht ausgeliefert).
Wäre prinzipiell nur für die Router problematisch die nur reine Mesh Router sind und auch nur da die, die mit einen stable Router Meshen.
Ich denke wir sollten aufhören die Problematik mit den v10 Geräten als Mischung zu sehen. Eine Mischung tritt nur mit der manuellen Platzierung in einem Verzeichnis und einem Manifest auf. Ansonsten sind es schlicht zwei Entwicklungszweige, die aktuell parallel gepflegt werden müssen (mit zeitlicher Beschränkung!).
Das ist richtig. Ich bin mir unsicher wie ich mich da positionieren soll. Ich würde diese Variante anwenden um die v10 die auf stable lauschen auf testing umzubiegen. Dann könnte man über testing die hood packages für den gluon master ausrollen unabhängig von der Stable gluon 2015.x. vg Tarek
Wie seht ihr das? Wie wollen wir vor gehen?
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.
+1
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
Ich würde ebenfalls den 1. Part präferieren. Im Grunde kann der auch so aus sehen: Version Stable 0.7: Auslieferung des Hoodselectors 2015.x Version Testing 0.7-gluon2016: Auslieferung des Hoodselectors 2016.x Bis zu diesem Punkt ist der zustand des Netzes Identisch zum jetzigen stand. Bei den v10 die Aktuell im Einsatz sind ist das mein verschulden das diese Standardmäßig auf stable zeigen, da ich das so compiliert habe. Diese sollten auf testing umgestellt werden. Version Stable 0.7.1: Aktivierung der ersten Hood Version Testing 0.7.1-gluon2016: Aktivierung der ersten Hood Version x 0.7.x: Bugfixing der neuen Netzstruktur Version 0.8: Update auf Gluon 2016.1 Ab hier würden alle bis zum jetzigen Zeitpunkt aktiven v10 Router die auf testing sind und auf stable lauschen updaten auf Stable. Version 0.8.x: Bugfixing von Gluon 2016.1
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.
Dem stimme ich voll zu! Das ist auch das was ich immer allen sage das testing eben Testing ist und es durchaus dazu kommen kann das die Router z.b. beim nächsten update gebrigt sind. dazu gibt es übrigens auch ein issue, das die Router im aktuellen Master wohl beim autoupdaten bricken können. https://github.com/freifunk-gluon/gluon/issues/585 vg Tarek
Hi, was sagt der Bug denn genau aus? Funktioniert der Autoupdater nun gar nicht mehr oder nur teilweise? Am 21.01.2016 um 14:28 schrieb Jan-Tarek Butt via Dev:
Dem stimme ich voll zu! Das ist auch das was ich immer allen sage das testing eben Testing ist und es durchaus dazu kommen kann das die Router z.b. beim nächsten update gebrigt sind. dazu gibt es übrigens auch ein issue, das die Router im aktuellen Master wohl beim autoupdaten bricken können. https://github.com/freifunk-gluon/gluon/issues/585 -- Viele Grüße
Stefan
On 01/21/16 14:42, Stefan via Dev wrote:
Hi,
was sagt der Bug denn genau aus? Funktioniert der Autoupdater nun gar nicht mehr oder nur teilweise?
Der Autoupdater funktioniert. Es kann aber vorkommen das Router nicht updaten sondern vorher abstürzten weil die kein RAM mehr haben. Die Wahrscheinlichkeit tritt stärker auf wenn IBSS und IEEE 802.11s Parallel aktiv sind. Das ist bei uns der Fall. vg Tarek
Kommt hier noch was ? Hab das Gefühl das wir hier noch einwehnig diskutieren sollten. Zumindest bin ich mir gerade noch nicht schlüssig wie wir weiter machen sollen ... vg Tarek
Mein Anliegen ist, dass v10 Geräte und Nutzer nicht auf die Schiene "egal" oder "selber schuld" abgeschoben werden, sondern genau so ernst genommen werden wie stable User. Die testing ist schließlich das stabilste, was es für v10 gibt und der 841n ist DER Standardrouter schlechthin. Am 24.01.2016 12:13 schrieb "Jan-Tarek Butt via Dev" <dev@lists.ffnw.de>:
Kommt hier noch was ?
Hab das Gefühl das wir hier noch einwehnig diskutieren sollten. Zumindest bin ich mir gerade noch nicht schlüssig wie wir weiter machen sollen ...
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Sonntag, 24. Januar 2016, 12:46:35 CET schrieb Simon Kurka via Dev:
Mein Anliegen ist, dass v10 Geräte und Nutzer nicht auf die Schiene "egal" oder "selber schuld" abgeschoben werden, sondern genau so ernst genommen werden wie stable User. Die testing ist schließlich das stabilste, was es für v10 gibt und der 841n ist DER Standardrouter schlechthin.
Hi, ernst nehmen ja, Support nein. Wer knappe Ressourcen hat, der muss Prioritäten setzen und bei dem Berg offener Projekte steht Support für testing-Firmware bei mir an allerletzter Stelle. Die Ansage ist ganz klar: ja wir besitzen WR841NDv10 Router, aber mit dem Alltagseinsatz dieser Router wird gewartet bis dafür eine stabile Firmware verfügbar ist. Wir brauchen nicht Wachstum auf Kosten der Firmwarestabilität und damit auf Kosten der Entwickler. In einem Punkt hast du Recht: wir haben einige Benutzer, die einen WR841NDv10 im Einsatz haben und diesen unglücklicher Weise auch noch fehlkonfiguriert haben. Wir sollten nicht einhergehen und diese Router mutwillig außer Betrieb nehmen. Sondern wir sollten mit diesen Benutzern Kontakt aufnehmen und sie darauf hinweisen, dass sie eine Testing-Firmware einsetzen, die falsch konfiguriert ist und dadurch in kürze nicht mehr funktionieren wird. Glücklicher Weise kann man das Problem aber beheben, indem man seinen Autoupdater-Channel auf testing setzt. Dann passiert erstmal nichts schlimmes. Wir haben mehr als unsere Pflicht getan und sogar Support für eine unsupportete Firmware geleistet und jeder Benutzer kann sich 2-3 Wochen überlegen, ob er lieber einen toten Router hat oder doch besser die Config ändert. Dann können wir nämlich auch ganz entspannt Pfad 1 gehen und in 2-3 Wochen die nächste Firmware releasen. LG Clemens
Moin, wir sollten hier wirklich eine Lösung finden, die für alle aktzeptabel ist. Vielleicht kann man ja wirklich ein paar User dazu bewegen, den Autoupdater auf Testing umzustellen. Kriegen wir die entsprechenden Router nicht durch ein kleines FW Update auf testing umgestellt? Am 24.01.2016 um 12:46 schrieb Simon Kurka via Dev:
Mein Anliegen ist, dass v10 Geräte und Nutzer nicht auf die Schiene "egal" oder "selber schuld" abgeschoben werden, sondern genau so ernst genommen werden wie stable User. Die testing ist schließlich das stabilste, was es für v10 gibt und der 841n ist DER Standardrouter schlechthin.
Am 24.01.2016 12:13 schrieb "Jan-Tarek Butt via Dev" <dev@lists.ffnw.de <mailto:dev@lists.ffnw.de>>:
Kommt hier noch was ?
Hab das Gefühl das wir hier noch einwehnig diskutieren sollten. Zumindest bin ich mir gerade noch nicht schlüssig wie wir weiter machen sollen ...
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de <mailto:Dev@lists.ffnw.de> https://lists.ffnw.de/mailman/listinfo/dev
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- --- Viele Grüße Stefan
Kriegen wir die entsprechenden Router nicht durch ein kleines FW Update auf testing umgestellt?
Nein. Wenn wir das könnten wäre die Lösung sehr einfach. Aber diese testing Router sind so konfiguriert, dass sie ihre Updates aus stable statt aus testing beziehen. Das heißt wir können kein Testing-Update speziell für diese Router ausliefern, sondern nur ein Stable-Update welches dann alle beziehen. Und dieses Update muss mit einem Gluon 2016.1 als Basis ausgeliefert werden, sonst versagen die falsch konfigurierten Router den Betrieb. Im Gluon 2016.1 Image sind aber diverse schwere Bugs, unter anderem ein Bug im Autoupdater der bei einigen Routern ebenfalls zum Totalversagen führt und da beißt sich die Katze in den Schwanz.
Vielleicht kann man ja wirklich ein paar User dazu bewegen, den Autoupdater auf Testing umzustellen.
Das ist nicht wirklich eine Option sondern mehr so eine Zwangsempfehlung. Es sei denn, wir wollen Pfad 2. Aber Pfad 2 bedeutet keine Updates auszuliefern, bis Gluon 2016.1 released, getestet und in einer Firmware verpackt ist. LG Clemens
Wie wollen wir denn hier alle v10 User erreichen? Sofern Kontaktdaten im ALFRED mit gesammelt wurden wäre ja eine Email das sinnvollste - zusätzlich natürlich, Blog, Facebook und was dazu gehört. Am 25.01.2016 um 10:08 schrieb Clemens John via Dev:
Das ist nicht wirklich eine Option sondern mehr so eine Zwangsempfehlung. Es sei denn, wir wollen Pfad 2. Aber Pfad 2 bedeutet keine Updates auszuliefern, bis Gluon 2016.1 released, getestet und in einer Firmware verpackt ist.
On 25.01.2016 10:08, Clemens John via Dev wrote:
Das heißt wir können kein Testing-Update speziell für diese Router ausliefern, sondern nur ein Stable-Update welches dann alle beziehen. Und dieses Update muss mit einem Gluon 2016.1 als Basis ausgeliefert werden, sonst versagen die falsch konfigurierten Router den Betrieb.
Das stimmt so nicht. Man kann unterschiedlichste Firmwares pro Router-Modell ausliefern, warum lägen sonst mehrere Firmware-Files im stable Verzeichnis. Man kann auch ein komplettes stable release ausrollen und nur die Firmware für die v10 Geräte vorhalten. Die Folge wäre, dass nur die v10 Geräte updaten. Mein Wunsch ist weiterhin die v10 Firmware parallel zu pflegen und speziell diese beiden Firmware-Files mit in den stable Zweig zu nehmen. Die v10 Geräte würden die dev-Version von gluon erhalten, alle anderen Geräte sind in keiner Weise betroffen. Zu beachten gilt lediglich, dass man vor Erreichen der Signaturgrenze ein v10 Gerät getestet haben sollte und schon hätten wir auch eingeschränkten Support. -- Viele Grüße, Simon
Hi,
Das stimmt so nicht. Man kann unterschiedlichste Firmwares pro Router-Modell ausliefern, warum lägen sonst mehrere Firmware-Files im stable Verzeichnis.
Man kann auch ein komplettes stable release ausrollen und nur die Firmware für die v10 Geräte vorhalten. Die Folge wäre, dass nur die v10 Geräte updaten.
Wenn die manifeste vom 2015.x und vom 2016.1 Gluon miteinander kompatibel sind, dann wäre das ja wirklich eine Lösung. Magst du das mal checken? Viele Grüße Clemens
Moin vielleicht habe ich es ja auch überlsen. Wann ist den das geplannte Firmware Release von 2016.1 ?! Gruß Johannes Am 2016-01-25 12:09, schrieb Clemens John via Dev:
Hi,
Das stimmt so nicht. Man kann unterschiedlichste Firmwares pro Router-Modell ausliefern, warum lägen sonst mehrere Firmware-Files im stable Verzeichnis.
Man kann auch ein komplettes stable release ausrollen und nur die Firmware für die v10 Geräte vorhalten. Die Folge wäre, dass nur die v10 Geräte updaten.
Wenn die manifeste vom 2015.x und vom 2016.1 Gluon miteinander kompatibel sind, dann wäre das ja wirklich eine Lösung. Magst du das mal checken?
Viele Grüße Clemens _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Montag, 25. Januar 2016, 12:31:38 CET schrieb johannes.rudolph--- via Dev:
vielleicht habe ich es ja auch überlsen.
Nein. Ein genaues Releasedatum ist weder geplant noch absehbar. Die aktuelle Diskussion dreht sich darum was überhaupt Bestandteil der nächsten Version werden soll. Im Anschluss daran startet dann die Entwicklung. Falls du das Releasedatum von Gluon 2016.1 meinst, soweit ich weiß ist die offizielle Aussage dort "when it's done". Viele Grüße Clemens
On 01/25/16 15:08, Clemens John via Dev wrote:
Am Montag, 25. Januar 2016, 12:31:38 CET schrieb johannes.rudolph--- via Dev:
vielleicht habe ich es ja auch überlsen.
Nein. Ein genaues Releasedatum ist weder geplant noch absehbar. Die aktuelle Diskussion dreht sich darum was überhaupt Bestandteil der nächsten Version werden soll. Im Anschluss daran startet dann die Entwicklung.
Falls du das Releasedatum von Gluon 2016.1 meinst, soweit ich weiß ist die offizielle Aussage dort "when it's done".
Ich hatte die Info bekommen das es Mitte Februar soweit sein soll allerdings hallte ich das nach aktuellen stand für unrealistisch... vg Tarek
Hi,
Das stimmt so nicht. Man kann unterschiedlichste Firmwares pro Router-Modell ausliefern, warum lägen sonst mehrere Firmware-Files im stable Verzeichnis.
Man kann auch ein komplettes stable release ausrollen und nur die Firmware für die v10 Geräte vorhalten. Die Folge wäre, dass nur die v10 Geräte updaten.
Wenn die manifeste vom 2015.x und vom 2016.1 Gluon miteinander kompatibel sind, dann wäre das ja wirklich eine Lösung. Magst du das mal checken?
Sind logischerweise kompatibel sonst könnten Router von v2015.x nicht auf v2016.x updaten. Ich würde das dann so umsetzen. Allerdings möchte ich nochmal darauf hinweisen das ein autoupdate dazu führen kann das einigen testing Geräte gebrickt werden könnten... vg Tarek
Moin, es müsste doch technisch möglich sein, eine FW zu bauen in der nur die v10 images mit einem manifest enthalten sind um auf den testing Autoupdater zu switchen. Sprich eine FW zu bauen in der nur das v10 image enthalten ist und auch nur dieses im manifest mit der chechsum. Danach sollte ja einen richtigen Update nichts im Wege stehen. Am 26. Januar 2016 05:32:03 MEZ, schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Hi,
Das stimmt so nicht. Man kann unterschiedlichste Firmwares pro Router-Modell ausliefern, warum lägen sonst mehrere Firmware-Files
im
stable Verzeichnis.
Man kann auch ein komplettes stable release ausrollen und nur die Firmware für die v10 Geräte vorhalten. Die Folge wäre, dass nur die v10 Geräte updaten.
Wenn die manifeste vom 2015.x und vom 2016.1 Gluon miteinander kompatibel sind, dann wäre das ja wirklich eine Lösung. Magst du das mal checken?
Sind logischerweise kompatibel sonst könnten Router von v2015.x nicht auf v2016.x updaten. Ich würde das dann so umsetzen. Allerdings möchte ich nochmal darauf hinweisen das ein autoupdate dazu führen kann das einigen testing Geräte gebrickt werden könnten...
vg Tarek
------------------------------------------------------------------------
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan
Am Dienstag, 26. Januar 2016, 06:19:06 CET schrieb Stefan via Dev:
es müsste doch technisch möglich sein, eine FW zu bauen in der nur die v10 images mit einem manifest enthalten sind um auf den testing Autoupdater zu switchen.
Sprich eine FW zu bauen in der nur das v10 image enthalten ist und auch nur dieses im manifest mit der chechsum.
Danach sollte ja einen richtigen Update nichts im Wege stehen.
Hi, jo ich glaube das war auch der Plan den Tarek meinte. Einige v10 Router werden wahrscheinlich trotzdem ihren Dienst versagen, weil das Gluon 2016.1 einen schweren Fehler im Autoupdater enthält. Wie gesagt es ist insgesamt keine gute Idee Testing Images im Produktiveinsatz zu verwenden und darauf sollten wir auch noch einmal im Blog hinweisen. LG Clemens
On 01/26/16 09:07, Clemens John via Dev wrote:
Am Dienstag, 26. Januar 2016, 06:19:06 CET schrieb Stefan via Dev:
es müsste doch technisch möglich sein, eine FW zu bauen in der nur die v10 images mit einem manifest enthalten sind um auf den testing Autoupdater zu switchen.
Sprich eine FW zu bauen in der nur das v10 image enthalten ist und auch nur dieses im manifest mit der chechsum.
Danach sollte ja einen richtigen Update nichts im Wege stehen.
Hi,
jo ich glaube das war auch der Plan den Tarek meinte.
genau :)
Einige v10 Router werden wahrscheinlich trotzdem ihren Dienst versagen, weil das Gluon 2016.1 einen schweren Fehler im Autoupdater enthält. Wie gesagt es ist insgesamt keine gute Idee Testing Images im Produktiveinsatz zu verwenden und darauf sollten wir auch noch einmal im Blog hinweisen.
Ein blog Hinweis ist ne gute idee. Dadurch das es sich um Testing Firmwares handelt und in Testing per default eine andere BSSID und SSID verwendet wird. Kann es sein das einzelne Router die via Mesh an Stable Routern hängen offline gehen. Ich würde das gerne so bei behalten das die Netze Hart getrennt sind. Sind alle damit einverstanden (oder muss zwingend eine Äquivalenz bestehen?) Hinweis: bei einer ungleichen BSSID sehen sich die Router nicht mehr. vg Tarek
Hi, was soll in dem betreffenden Blog Eintrag denn ansatzweise stehen? ich würde dann hier wohl einmal was vorschreiben und hier auf die Dev Liste vorschlagen. Vg, Stefan Am 26.01.2016 um 12:18 schrieb Jan-Tarek Butt via Dev:
On 01/26/16 09:07, Clemens John via Dev wrote:
Am Dienstag, 26. Januar 2016, 06:19:06 CET schrieb Stefan via Dev:
es müsste doch technisch möglich sein, eine FW zu bauen in der nur die v10 images mit einem manifest enthalten sind um auf den testing Autoupdater zu switchen.
Sprich eine FW zu bauen in der nur das v10 image enthalten ist und auch nur dieses im manifest mit der chechsum.
Danach sollte ja einen richtigen Update nichts im Wege stehen.
Hi,
jo ich glaube das war auch der Plan den Tarek meinte.
genau :)
Einige v10 Router werden wahrscheinlich trotzdem ihren Dienst versagen, weil das Gluon 2016.1 einen schweren Fehler im Autoupdater enthält. Wie gesagt es ist insgesamt keine gute Idee Testing Images im Produktiveinsatz zu verwenden und darauf sollten wir auch noch einmal im Blog hinweisen.
Ein blog Hinweis ist ne gute idee.
Dadurch das es sich um Testing Firmwares handelt und in Testing per default eine andere BSSID und SSID verwendet wird. Kann es sein das einzelne Router die via Mesh an Stable Routern hängen offline gehen. Ich würde das gerne so bei behalten das die Netze Hart getrennt sind. Sind alle damit einverstanden (oder muss zwingend eine Äquivalenz bestehen?)
Hinweis: bei einer ungleichen BSSID sehen sich die Router nicht mehr.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
es müsste doch technisch möglich sein, eine FW zu bauen in der nur die v10 images mit einem manifest enthalten sind um auf den testing Autoupdater zu switchen.
Sprich eine FW zu bauen in der nur das v10 image enthalten ist und auch nur dieses im manifest mit der chechsum.
Danach sollte ja einen richtigen Update nichts im Wege stehen.
Ja das ist aktuell der Plan. vg Tarek
Hi,
Man kann auch ein komplettes stable release ausrollen und nur die Firmware für die v10 Geräte vorhalten. Die Folge wäre, dass nur die v10 Geräte updaten.
Mein Wunsch ist weiterhin die v10 Firmware parallel zu pflegen und speziell diese beiden Firmware-Files mit in den stable Zweig zu nehmen. Die v10 Geräte würden die dev-Version von gluon erhalten, alle anderen Geräte sind in keiner Weise betroffen. Zu beachten gilt lediglich, dass man vor Erreichen der Signaturgrenze ein v10 Gerät getestet haben sollte und schon hätten wir auch eingeschränkten Support.
Hier Haben wir wieder ein Problem Es muss zuvor ein gepatchter autoupdater ausgerollt werden + eine umbiegung auf den testing baranch. Ich weiß nicht wie viele Router mit dem gepatchten autoupdater von dem v10ern überleben würden :S .... Mir fällt da irgendwie keine schöne Lösung ein. Die einzige die mir ein fällt wäre das cachig des gesamten Firmware Images im RAM weg zulassen und die zeitliche Verzögerung aus zu nutzen. Das würde allerdings dazu führen das Mesh Router mit >=3 hops potentiell offline gehen ohne sich ein update ziehen zu können. Nun da müssten wir abwägen wie viele Mesh Router mit der v10 >=3 hops existieren... Eins kann ich ziemlich sicher sagen das Cachen des Gesamten Firmware Images über 6h werden die Router mit Caos Calmar nicht packen. vg Tarek
participants (6)
-
Clemens John -
Jan-Tarek Butt -
johannes.rudolph＠rudolphmedia.de -
Simon Kurka -
Simon Kurka -
Stefan