ich lege hier nach Vorbild des Admintagebuchs einfach mal ein Firmwaretagebuch an, wo @Alucardo, ich und natürlich auch jeder andere, der Spaß am Firmwarebauen hat, dokumentieren können, was sich so geändert hat.
Ich habe heute Nacht eine erste Firmware für Selm gebaut. Da wir uns letztens Mittwoch darauf geeinigt hatten, die relativ instabilen Versionen v2016.1.3 und v2016.1.4 nicht weiter auszurollen, probiere ich dazu jetzt mal den aktuellen Entwicklungszweig v2016.1.x. Der ist nicht ganz so experimentell wie der master an sich und wir können immer noch mittels Commits unsere eigenen Versionen festsetzen.
Dieses Thema ist nun angepinnt. In seiner Kategorie wird es nun oben aufgelistet, solange der Pin nicht von einem Moderator gelöst wird, oder nicht jeder Nutzer selbst den Pin löst.
Das ist doch redudant zu den Commits bzw Issue Historie? Warum das doppelt halten?
Changelog macht man™ per SCM und nicht per Hand. Üblicherweise damit man auch weiss was denn nun exakt in welchem Branch/Tag gelandet ist. Würde dementsprechend vorschlagen das hier einzustellen.
Die Commit-Historie ist bei mittlerweile ~27 Zweigen aber relativ unübersichtlich und sehr technisch. Hier geht es darum, einen Überblick zu geben, welche Firmware was kann.
Die Zielgruppe hier sind die Nutzer. Im Admintagebuch ist das Ziel die anderen Admins auf dem Laufenden zu halten.
So nach kleinem Test bei mir zu Hause habe ich den Commit von @MPW auf die anderen Branches ausgeweitet. Jetzt verbindet sich der Tunneldigger nicht mehr immer mit dem selben GW sonder wechselt.
Firmware für jede Domäne wird demnächst online stehen. (Jenachdem wie schnell der Server baut. ;))
Für Warendorf habe ich eine v2016.1.4+ gebaut, dass u.a. Firmware für den 841v11 enthält. Diese befindet sich im latest Zweig.
Den experimental Zweig hab ich auf v2016.1.4 gehoben. Darin wird der Anwender u.a. aufgefordert den Knoten anzumelden, damit wir zur primären MAC auch Kontakte haben.
Weil das sooo glatt durchgegangen ist, baue ich auch gerade einen neuen stable der auf v2016.1.4 basiert. Der sollte in den nächsten Stunden im stable Zweig erscheinen.
Alle v2016er laufen doch nicht rund. Darum gehen einige Communities zurück auf v2015.1.2. Am Mittwoch haben wir beschlossen, auf die Flucht nach vorne zu warten.
Ich kenne mich im Detail auch nicht damit aus. Die V2016.1.y sollen alle eine schlechtere Funkleistung als v2015.1.2 haben und die Bootschleife von v2016.1.4 tritt halt auch höchstens beim Booten auf.
Wir probieren es jetzt mal mit v2016.1.x. Wenn du gut läuft, nehmen wir erstmal die.
Ich habe die 2016.1.4-2 für Warendorf jetzt signiert und die Updates sollten gleich losgehen. Wäre nett, wenn jemand die Firmware auf firmware.freifunk-muensterland.org syncen würde: Ich weiß noch nicht wie das geht. Danke!
ps: config.js habe ich gefunden, und da steht noch ein “proxy_to: domaene14”, was da wahrscheinlich weg sollte: wir haben uns schon einen irrläufer eingefangen
Auch für Warendorf ist der Bau der v2016.1.5 angelaufen. Zuerst mache ich ein experimental. Wenn das läuft schließe ich den latest-Zweig und schiebe alle in den experimental Bereich. Danach schließe ich den experimental-Zweig und schiebe alle ins stable.
Denke darüber nach, Knoten die ohne Grund auf alter Firmware laufen aus dem VPN auszuschließen. Die Diskussion ist damit eröffnet
Proxy für die neuen Domänen ab 32 jetzt deaktiviert und die alte Firmware nach /root verschoben. Wer nochmal was aus Domäne 02 oder 14 braucht, muss @Alucardo oder mich anschreiben. Eigentlich soll nur noch die neue verwendet werden.
Ich habe gestern noch die 1.1.4 für die Domäne 07 bis 13 gebaut.
