Re: Nächstes Release

Fabian Bläse fabian at blaese.de
So Nov 10 14:54:55 CET 2019


Hallo Adrian,

On 07.10.19 14:59, Adrian Schmutzler wrote:
> Hallo,
> 
>> Hey zusammen, 
>> es hat sich jetzt ganz schön lange gezogen, aber ich würde gerne demnächst wieder ein Release (diesmal inklusive beta (und ggf. alpha)) anpeilen.
>> Vorher ist noch folgendes zu klären: 
>> == Beide Varianten immer gleichzeitig veröffentlichen oder eigene Releases machen? == 
>> Zweiteres hätte den Vorteil, dass man unabhängig veröffentlichen kann; lässt sich in unserer aktuellen git-Struktur aber nur unschön umsetzen, da Tags für beide Varianten gelten.
> 
> Du sagst es ja im Prinzip, im Prinzip muss beides released werden.
> 
> Da sich bei der Knoten-Firmware eh nichts mehr tut, muss man im Prinzip dann auch nur kucken, dass nichts kaputt gegangen ist...
Das ist jetzt arg pessimistisch formuliert.
Aktuell lag der Fokus halt auf der Gateway-Variant, wie wir das auf dem persönlichen Entwicklertreffen auch mal als Projekt nach Fertigstellung des KeyXv2 besprochen hatten. (was leider viel zu lange gedauert hat..)

Ob sich jetzt wieder jemand findet, der da aktiver Patches baut, werden wir sehen müssen.

>> == Upgrades == 
>> Es muss geprüft werden, ob sysupgrade.sh sauber funktioniert und zwischen den Varianten unterscheiden kann. 
>> Weiterhin müssen wir dann voraussichtlich daran denken, passende Rewrites auf dem Server einzuführen, da die aktuellen Versionen keine Variantenunterscheidung im Dateinamen kennen.
>> Am besten wäre, wenn wir das auf dem Server in eigene Unterordner ablegen könnten. Dazu muss sysupgrade.sh entsprechend angepasst werden.
> 
> Da halte ich mich tendenziell raus, da ich das nicht verwende.
> Für die Zukunft sei darauf hingewiesen, dass das alles noch viel hässlicher wird, wenn die geänderten Namen durch ath79 irgendwann kommen (ein bisschen schon für die anderen Targets in 19.07, z.B. tplink_tl-wdr4900-v1 statt tl-wdr4900-v1...).
Ja, wird es. Fixen wir per rewrites auf dem Webserver. Da sind auch schon einige gruselige Dinge von $vielfrüher drin.. ;)

> 
> Bei mir liegt das Upgrade-Skript gar nicht mehr auf dem Knoten, sondern wird vom Server heruntergeladen, was Vor- und Nachteile mit sich bringt...
Halte ich für die gemeinsam entwickelte Variante nicht für erstrebenswert.
Da aber im Updateprozess eh keine Zertifikate o.ä. geprüft werden, wäre es aber vermutlich eh nicht so dramatisch, man kann den Routern auch jetzt schon alles unterjubeln.

>> == Fehlende Patches == 
>> Aktuell halte ich noch folgende Patches für Releasekritisch: 
>> - nodewatcher: babel version und babel neighbours 
> 
> Version ist gerade applied worden, neighbors steht noch aus.
> 
>> - fff-gateway: Add examples (Kann man für alpha ggf. noch weglassen) 
> 
> Halte ich wenig davon, dafür Aufwand zu betreiben und Speicher zu belegen. Da aber Tim und Fabian glaube ich dafür waren: ich habe auch kein Problem damit.
> 
>> - fff-network: Remove dependency to uradvd 
> 
> Das ist zwar Pfusch, aber von mir aus rein damit.
Ist es, ist ja auch nur ein Workaround, bis das configurenetwork ordentlich gefixt wird.

>> - fff-wireless: Add gateway configuration scripts (oder irgendeine andere Art WLAN-AP zu konfigurieren, ggf. kann man es da auch einfach beim OpenWRT Weg belassen, was dann aber nicht Upgradefest ist)
> 
> Ich bin nach wie vor für das Hood File, daher werde ich mich mit diesem Aspekt wenig befassen.
Ich hatte mir das so gedacht, dass das Hood File dann vom Gateway - falls jemand ein Hoodfile-Host Paket bauen möchte - automatisch aus der Konfiguration erzeugt wird.
Dann müsste man nur noch ein paar Mesh-Variablen einführen und dann muss man das Hoodfile nicht mehr manuell anfassen.

>> - Move node-specific firewall rules to fff-node 
> 
> Ja, das muss ich mir noch genau ansehen.
> 
>> - "fff-network: enable accept_ra" bzw. "move device specific setings after global settings to avoid overwriting", je nachdem, welche Lösung wir finden
> 
> Muss ich mir auch noch ankucken.
beide applied, du darfst aber trotzdem gerne noch drüber sehen.

>> Falls hier noch jemand etwas anderes hat, was auf jeden Fall bis zum Release dabei sein sollte: Bescheid sagen! :-) 
> 
> Ich würde tatsächlich gerne die Buildscript-Änderungen und den Package-Cleanup für die Varianten noch mit aufnehmen:
> [v3,1/3] buildscript: Do not use target-dependent build directory
> [v3,2/3] buildscript: Remove obsolete target variable
applied.

> [v3] packages/fff: Merge meta packages for variants into config packages
reviewed.

Gruß
Fabian

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: OpenPGP digital signature
URL         : <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20191110/067b8f46/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev