Erstellen eines release candidate branchs mit der Bezeichnung "testing"

[indigo423]

Für release candidate Firmware wird ein Testing branch verwendet. Änderungen in diesem Branch sind für Fehlerbehebung. Der Development branch wird zur Entwicklugn verwendet und wird häufiger geändert und wird daher auch häufiger kaputt gehen.

[indigo423]

• Wiki Firmware aktualisiert
• Index page auf downloads.fulda.freifunk.net aktualisiert
• In development branch für site-fffd testing als branch hinzugefügt.
• CI System testing branch angelegt
• Branches für testing in gluon und site-fffd repository angelegt

[fooker]

Der "Wörkflow" ist dann also Development -> Testing -> Stable. Richtig?

Die Site-Config muss noch so angepasst werden, dass der Branch im Autoupdater auftaucht. Vlt. kann Development dann auch entfernt werden.

Wi ist das Signierungs-Schema für Testing. Genügt eine Signatur oder gibt es Releases, die von mehreren Personen signiert werden?

Wie kompatibel sollen Development und Testing denn gehalten werden? Ab wann sind migrationwn nötig?

[indigo423]

Das ist richtig, development kann kaputt sein, alles was von develop brauchbar rausfällt schieben wir nach testing und dann ins nächste stable.

Ich habe in der site-fffd im development banch testing mit angelegt:

https://github.com/freifunk-fulda/site-fffd/commit/e21eee09ec22b8034d4d7280760a8d28b25e39d5

Die Signatur-Policy hab ich erstmal übernommen, 1 good signature und Jenkins signiert das. Ich sehe Testing wirklich so, dass wir versierten Leute sagen können, probiert die Firmware aus. Aus unserer Sicht müsste eigentlich alles gehen.

Bei Develop würde ich erwarten dass Sachen nur eingeschränkt funktionieren, die Knoten sich nur auf bestimmte Gateways verbinden oder andere komische Sachen die beim entwickeln der Firmware notwendig sind.

Ein ganz gutes Beispiel ist das private WLAN was momentan in development geht. Prinzipiell haben wir das mal freigeschaltet nach dem Motto müsste eigentlich gehen. Sowas ist in Testing ganz gut aufgehoben, die Leute die es brauchen können das ausprobieren und Feedback geben. Den anderen macht man nix kaputt. In Development können wir weiter Dinge absichtlich kaputt machen und wir gehen denen die ein paar neue features in Testing ausprobieren wollen nicht andauernd auf den Sack :)

[fooker]

Ok. Verstehe. Sollten wir Development dann aus dem Autoupdater entfernen?

[indigo423]

Guter Punkt - Könnten wir mal auf die Liste schieben ;)

[SISheogorath]

Was machen wir mit denen, die noch auf development sind und auf testing wechseln wollen/müssten? Die würden ja eigentlich erstmal per autoupdate weiter development ziehen. Das könnte hässlich werden. Wie kommunizieren wir das am besten?

[indigo423]

Ich hab mal was dazu in die Freifunk-Fulda Liste geschoben. Mal sehen was passiert, sind ja eh nur 3 mit development.

[reissmann]

Auf development sind laut meshviewer derzeit 3 Knoten. Davon ist einer mein eigener und einer duerfte der von Daniel sein, der aber autoupdates deaktiviert hat. Wer der dritte ist, weiss ich nicht.

[mortzel]

2 weiter Router mit development werden von mir betrieben.

[reissmann]

Idealerweise sollten alle auf testing umstellen.

Fuer development sollten wir vermutlich kein autoupdate anbieten, damit nicht einer die Router der anderen abschiesst, wenn etwas getestet wird.

[mortzel]

Meine Router sind mittlerweile auf 'testing-2' umgstellt und Autoupdat wurde auch auf Testing umgestellt.

Laut Meshviewer gibt es nur noch den Router von Dainel, der mit 'development-37' jedoch ohne autoupdate läuft.