Freifunk Kreis Schleswig-Flensburg:Firmware/Leitfaden zum signen

Aus wiki.freifunk.net
Zur Navigation springenZur Suche springen


Auf dieser Seite wird beschrieben wie im Kreis Schleswig-Flensburg mit neuen Versionen umgegangen werden soll und was passieren muss bevor gesigned wird. Wichtig zu bemerken ist, dieses Dokument kann sich ändern und ist nicht endgültig.

Schritt 1

Ein Entwickler meldet eine neue Version an. Dies kann sowohl eine neue Gluon Version sein sowie lokale Änderungen. In beiden fällen werden die Versionen in der site.mk angepasst und darauf eine PullRequest Richtung staging branch geöffnet. In keinem Fall wird die master branch direkt bearbeitet. Sobald eine Pull Request vorliegt werden die Signer informiert.

Dieser Schritt bedeutet zusätzlich die Freigabe zum testen für "Mutige".

Schritt 2

Signer gucken sich sowohl die Änderungen in der Site als auch unter den hauseigenen Paketen an und wenn nötig auch von fremd Paketen. Hierbei ist es nicht wichtig das der Code Syntax stimmen soll sondern Logik Fehler vermieden werden sollen. Außerdem muss nicht jeder alles sich an sehen.

Sollten in diesem Fall Auffälligkeiten passieren Kommentar unter die Pull Request schreiben und wenn nötig einen Link zu der Problem Stelle mitliefern.

Sollte man sich den Code nicht an sehen, dann sollte man wenn nötig kurz oder länger die Version testen. Ein sign darf nicht auf blindem Vertrauen passieren!

Schritt 3

Der Entwickler löst die Probleme oder Gluon Probleme werden als Issue in der Gluon Repository erstellt.

Hiernach ist zwingend die veränderte Firmware erneut zu testen. Also von Schritt 1 losgehen.

Schritt 4

Sobald alle Probleme geklärt wurden wird die Pull Request gegen staging gemerged und ein Autoupdate für die experimental Plattform bereitgestellt. Gleichzeitig wird eine neue Pull Request geöffnet von staging richtung master.

Hierbei soll die Firmware endgültig getestet werden. (Als Beispiel auf Probleme die beim autoupdate passieren)

Schritt 5

Nach x (zum Zeitpunkt wo dieser Beitrag erstellt wurde nicht definiert) ohne Bugs wird die Pull Request Richtung master gemerged und eine Stable Version für den Autoupdater bereitgestellt.

Nach Schritt 5 geht es mit der nächsten Version wieder bei Schritt 1 los.