Am 19. Juni 2015 19:03:34 MESZ, schrieb Jan-Tarek Butt tarek@ring0.de:
Am 19.06.2015 um 18:31 schrieb Bjoern Franke:
Am Freitag, den 19.06.2015, 15:43 +0200 schrieb Clemens John:
Am Freitag, 19. Juni 2015, 15:11:01 schrieb Jan-Tarek Butt:
Im Moment werden Änderungen aus dem master in den aktuellen Firmware branch gecherrypickt. Wo du das aber gerade ansprichst würde ich die Struktur ein wenig ändern wollen. Folgendes
Ok, ich behalte das mit dem cherrypicken für das aktuelle Updat
jetzt
erstmal bei bis wir uns da was schlaues überlegt haben.
Ich würde gerne einen Master(Stable) Branch wo über tags die unterschiedlichen Versionen Gesetzen werden. Einen Testing Branch zum testen (mit geänderte SSID) und einen komplett vom produktiven Netz getrennten Server Setup. Ein Backbone Branch um eine speziell angepasste Firmware für das backbone zu haben.
Für ein Testsetup: ja. Aber brauch wir fürs Backbone eigentlich Gluon?
Deswegen hab ich ja auch gesagt das ich da gerne einen extra Branch will ;-) oder willst du lieber ein ganzes extra repo ?
P.S. Ich finde wir sollten nicht jede Kleinigkeit in ein eigenes Firmware release Rausgeben. Mein vorschlagt das nächste Release wird erst gluon 2015.1.1 sein mit der release Nummer 0.6.
Ich wahr eigentlich ganz glücklich, dass wir mit dem Autoupdater auf
die "Release early, release often"-Strategie gewechselt sind. Den
Routern
ist es ziemlich egal wie oft sie geupdated werden und wir als Entwickler können Fehler nach einem Upgrade einfacher eingrenzen wenn jedes Release
nur
wenig Änderungen enthält.
Die "Feature Based Releases"-Strategie mit wenigen Releases, die viele Änderungen zusammenfassen macht zwar scheinbar weniger Arbeit weil der Release-Prozess nicht so häufig durchlaufen werden muss. Weil die Strategie mehr Änderungen pro Release mitbringt, verursacht die Strategie aber
auch mehr Probleme, die sich schwerer eingrenzen lassen. Diese Strategie sind wir lange gefahren und haben uns damit auch lange geärgert. Ich will dahin nicht zurück.
Ich würde lieber einen Kompromiss vorschlagen, bei dem wir weiterhin
"Release early, release often" anwenden aber Releases, die inkompatibel zueinander sind, explizit markieren z.B. indem sie als Major-Version herausgegeben werden.
ACK.
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Du willst einen nicht-gluon branch im siteconf-repo?