Super Ideen. Wir werden beides umsetzen. Die Datei von Wusel kann man auch einfach README.md nennen, dann wird die in GitHub auch gleich schon angezeigt.
Da könnte man dann eigentlich auch gleich eine generierte Index.HTML mit rein packen mit einem schönen Download selector
Das finde ich nun wiederum oversized; der Gluon-Build-Prozeß ist dokumentiert und basiert auf Commit-IDs, mit öffentlichen Repos und Commit-IDs ist nicht nur formal der GPL genüge getan.
Der Hintergrund für unsere »ReleaseNotes«-Datei ist schlicht der, das auch wir in der Lage sein wollen, zu einem Stand X, den wir ggf. aus Platzgründen schon wieder gelöscht haben, zurückkehren können wollen.
Hmm, die wird beim Build erzeugt, man müßte sie dann nach dem Build neu einchecken, was einen neuen Commit bedeutete, der automatisch einen neuen Build triggerte …
warum nicht. Wir haben das jetzt umgesetzt: https://freifunk.in-kiel.de/firmware/nightly/2018.1~ngly-245/
481K Jul 21 14:29 site.tgz
das ist glaube ich vertretbar und man kann sich das gleich lokal entpacken und loslegen 
Ihr könntet in dem Readme ja einen Platzhalter anlegen mit <!-- hier kommt die release note rein -->, der dann im buildprozess nur ausgetauscht wird, bevor die datei hochgeladen wird.
auch fertig:
https://freifunk.in-kiel.de/firmware/nightly/2018.1~ngly-245/site/download/
Hmm, Ihr baut das anders als wir
Index of /firmware/nightly
NameLast modifiedSizeDescription
Parent Directory -
2018.1~ngly-197/2018-07-14 21:31 -
2018.1~ngly-234/2018-07-21 05:40 -
2018.1~ngly-245/2018-07-21 23:01 -
factory/2018-07-21 14:37 -
sysupgrade/2018-07-21 14:45 -
Apache/2.4.23 (Debian) Server at freifunk.in-kiel.de Port 80
Index of /rawhide
NameLast modifiedSizeDescription
Parent Directory -
factory/2018-07-19 01:09 -
sysupgrade/2018-07-19 01:09 -
Apache/2.4.18 (Ubuntu) Server at firmware.4830.org Port 80
Aber letztlich Streit um des Kaisers Bart; jeder möge es so machen, wie es lokal konveniert …
? Ausgangspunkt war doch:
Um auf github die README.md zu ändern, muß ich doch eine neue Version committen. Das triggert unweigerlich einen neuen Build, da sich der Inhalt eines relevanten Repos geändert hat, …
das stimmt.
Ihr könntet aber den Teil, der sich nicht ändert in http://firmware.4830.org/rawhide/factory/ReleaseNotes-1.0.0~34 als Readme einchecken. den Teil der sich ändert dann mit <!-- einklammern und beim build austauschen bevor ihr den in eure firmware-download ordner kopiert.
kopfkratz Ich kann Dir nicht wirklich folgen, zudem liegt das Ergebnis des Baus auf http://firmware.4830.org, die Quellen zum Bau auf github. Warum man partout diese sinnvolle wie saubere Trennung durch commits nach dem Bau auflösen wollte, insbesondere im Lichte der Probleme, die für CI-Pipelines sich dadurch ergäben, erschließt sich mir nicht wirklich Nichts für ungut, aber ich denke, wir lassen unseren Kram so, wie er ist; Andere dürfen anders bauen 
Zurm Thema zurück:
Hmm. Wie verhindert dies, daß jemand einen »ver-malware-ten« Build macht und dort einfach die Infos der letzten offiziellen FW hardcoded? Das es ein »offizieller« Build ist, lernt der Autoupdater über den Hash, der von vertrauenswürdiger Seite signiert wurde. Wenn ein Build erstmal installiert ist, und jener war nicht koscher, ist das Kind doch schon in den Brunnen gefallen? Und mit den reinen Commit-IDs ohne die Repo-URL kann ich was anfangen? Gerade, wenn die Zombieapokalypse^W^W der github-Exodus kommt und lokale gitlab-Instanzen bevorzugt würden?
Dadurch ist es doch sicher, das man keine vermalwarete Firmware untergeschoben bekommen kann, oder?
Per AU. Heißt ja nicht, daß für manuelle Downloads (unterschiedliche Inhalte je nach Agent) nicht andere Dateien angebote werden oder auf einer anderen, pseudo-offiziellen (freifunk-entenhausen.de.com statt entenhausen.freifunk.net) Seite, „böse“ Images liegen?
Lies: das Autoupdate-Verfahren ist imho hinlänglich sicher, aber einen Sicherheitsgewinn durch die Angabe der Commit-IDs sehe ich nicht. Jedes Image müßte seine eigene Prüfsumme kennen und gegen die „offizielle“ prüfen, was bei einem Hobbyprojekt, wo jeder eigentlich die FW bauen können soll, irgendwie auch widersinnig ist?
Man müsste also in die Buildlogs die Signaturen (sha-whatever) aller genutzten Quellen mit angeben.