RE: Nächstes Release

[Adrian Schmutzler]

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...

> == 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...).

Bei mir liegt das Upgrade-Skript gar nicht mehr auf dem Knoten, sondern wird vom Server heruntergeladen, was Vor- und Nachteile mit sich bringt...

> == 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.

> - 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.

> - 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.

> 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
[v3] packages/fff: Merge meta packages for variants into config packages

Grüße

Adrian
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : openpgp-digital-signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <https://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20191007/1c72aade/attachment.sig>