Organisation des Siteconf Repos
Hi, mir ist im Moment nicht ganz klar wie das Siteconf Repo organisiert ist. Es gibt aktuell ja den master branch und den 0.5.6 branch. Die Images werden immer aus dem 0.5.6 branch gebaut, aktuelle Änderungen fließen idR. aber in den master ein. Wie werden Änderunen aus dem master in den 0.5.6 branch übernommen? Wird der master einfach komplett in den 0.5.6 branch gemerged oder machen wir für relevante commits ein cherrypick oder ein ganz anderes Verfahren? Dachte ich frage mal eben, dann kann ich meine Änderungen von gestern nämlich selbst an die passende Stelle schieben und den kompiler für die 0.5.6.3 anschmeißen. LG Clemens
Hi,
mir ist im Moment nicht ganz klar wie das Siteconf Repo organisiert ist.
Es gibt aktuell ja den master branch und den 0.5.6 branch. Die Images werden immer aus dem 0.5.6 branch gebaut, aktuelle Änderungen fließen idR. aber in den master ein.
Wie werden Änderunen aus dem master in den 0.5.6 branch übernommen? Wird der master einfach komplett in den 0.5.6 branch gemerged oder machen wir für relevante commits ein cherrypick oder ein ganz anderes Verfahren?
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 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. 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. Haben wir eigentlich inzwischen wieder einen Maintainer des Repos? LG Tarek
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.
Zustimmung.
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. Das wir derzeit so viele Mini-Releases haben ist ein wenig dem Umstand geschuldet, dass wir uns in einer Ausnahmesituation aufgrund des Batman Updates befinden. Glücklicher Weise bringen die Releases keine Inkompatibilitäten mit sodass niemand gezwungen ist zu Updaten.
Haben wir eigentlich inzwischen wieder einen Maintainer des Repos?
Indirekt dich weil du dich in letzter Zeit drum gekümmert hast :D LG Clemens
Am 19.06.2015 um 15:43 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.
OK.
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.
Zustimmung.
Stimmten dem weitere zu ?
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.
klinkt gut. Allerdings würde ich bevorzugen das wir zu jeden Release ein Blog Artikel schreiben, wo zumindest die Änderungen drinnen stehen. Denn für externe ist es leider nicht mehr ersichtlich was eigentlich in den ganzen Firmware Versionen geändert wird.
Das wir derzeit so viele Mini-Releases haben ist ein wenig dem Umstand geschuldet, dass wir uns in einer Ausnahmesituation aufgrund des Batman Updates befinden. Glücklicher Weise bringen die Releases keine Inkompatibilitäten mit sodass niemand gezwungen ist zu Updaten.
Haben wir eigentlich inzwischen wieder einen Maintainer des Repos?
Indirekt dich weil du dich in letzter Zeit drum gekümmert hast :D
Hm, ok :D LG Tarek
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Am 19.06.2015 um 17:31 schrieb Jan-Tarek Butt:
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.
Zustimmung.
Stimmten dem weitere zu ? hört sich für mich frischling gut an.
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. kling auch gut.
klinkt gut. Allerdings würde ich bevorzugen das wir zu jeden Release ein Blog Artikel schreiben, wo zumindest die Änderungen drinnen stehen. Denn für externe ist es leider nicht mehr ersichtlich was eigentlich in den ganzen Firmware Versionen geändert wird.
da bin ich auch für, damit die infos gepusched werden. mir ist transparenz sehr wichtig!
Haben wir eigentlich inzwischen wieder einen Maintainer des Repos? klar tarek ;)
oder kann das noch wer anders? ich würde an tareks seite eine hilfe gut finden. ideen, freiwillige? - -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVhRLCAAoJEF9yM4zWt58LGY4IAL2HNTY6UclczLC0rvhpMMMq A1/vR4h8FC7+8TcJdRrY4ZPgBdEE27deNxXBI23AtZA/M+XLM8MPAw9LrjtEC/2e 4rRBfTYaKbsi9Tjy5di4G7b2novek07O8egIB3JRxy/rD3BbSaDOYzYSAcY/E1H2 Bg2HWZkmDOpOM6ZbWR982mTB64VcPt+Nu0JCN09+eh37WNYTLaqrpga5IR37ocAw JGn+5gmHdiACflQB+Dva3Cos4ROMXDVwwJDu4Ncx79RNsy3Gr1Jb1lS2g/NlNjIn KlQqp1AOP9vW9CSzP2sY0oayDuIYYf2zbX9s4M1p40A+8E5SoK3GvU2L9fuiysg= =vseT -----END PGP SIGNATURE-----
Moin,
Zustimmung.
Stimmten dem weitere zu ?
Von diversen Anwendungen (Evolution, Gajim) kenn ich das andersrum, am Beispiel Gajim[1] wie folgt: master = Entwicklung gajim_0.16 = aktueller Stable-Branch Also quasi so, wie es bisher bei uns auch war. vg [1]http://hg.gajim.org/gajim/branches -- xmpp bjo@schafweide.org
Zustimmung.
Stimmten dem weitere zu ?
Von diversen Anwendungen (Evolution, Gajim) kenn ich das andersrum, am Beispiel Gajim[1] wie folgt:
master = Entwicklung gajim_0.16 = aktueller Stable-Branch
So bin ich es normalerweise auch gewohnt. Meine Idee war letztlich das wir zu dem autoupdater branches auch äquivalente Brauches im Repo haben.
Am Samstag, den 20.06.2015, 15:12 +0200 schrieb Jan-Tarek Butt:
Zustimmung.
Stimmten dem weitere zu ?
Von diversen Anwendungen (Evolution, Gajim) kenn ich das andersrum, am Beispiel Gajim[1] wie folgt:
master = Entwicklung gajim_0.16 = aktueller Stable-Branch
So bin ich es normalerweise auch gewohnt. Meine Idee war letztlich das wir zu dem autoupdater branches auch äquivalente Brauches im Repo haben.
Das wäre dann aber: master = nightly testing = testing stable = stable Ich wüsste nun keinen Grund, warum wir davon abweichen sollten. vg--xmpp bjo@schafweide.org
Da stimme ich bjo zu. Das sind die gängigen Kennzeichnungen. Am 20. Juni 2015 20:26:31 MESZ, schrieb Bjoern Franke <bjo@nord-west.org>:
Am Samstag, den 20.06.2015, 15:12 +0200 schrieb Jan-Tarek Butt:
Zustimmung.
Stimmten dem weitere zu ?
Von diversen Anwendungen (Evolution, Gajim) kenn ich das andersrum,
am Beispiel Gajim[1] wie folgt:
master = Entwicklung gajim_0.16 = aktueller Stable-Branch
So bin ich es normalerweise auch gewohnt. Meine Idee war letztlich das wir zu dem autoupdater branches auch äquivalente Brauches im Repo haben.
Das wäre dann aber:
master = nightly testing = testing stable = stable
Ich wüsste nun keinen Grund, warum wir davon abweichen sollten.
vg--xmpp bjo@schafweide.org
------------------------------------------------------------------------
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Viele Grüße, Stefan
Am 20.06.2015 um 20:26 schrieb Bjoern Franke:
Am Samstag, den 20.06.2015, 15:12 +0200 schrieb Jan-Tarek Butt:
Zustimmung.
Stimmten dem weitere zu ?
Von diversen Anwendungen (Evolution, Gajim) kenn ich das andersrum, am Beispiel Gajim[1] wie folgt:
master = Entwicklung gajim_0.16 = aktueller Stable-Branch
So bin ich es normalerweise auch gewohnt. Meine Idee war letztlich das wir zu dem autoupdater branches auch äquivalente Brauches im Repo haben.
Das wäre dann aber:
master = nightly testing = testing stable = stable
Ich wüsste nun keinen Grund, warum wir davon abweichen sollten.
Ja wir haben es nur leider nicht so ?? Im Grunde haben wir gerade: master = nightly && testing stable = $currend_firmware_version$ Ich finde deinen Vorschlag gut.
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?
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. -- xmpp bjo@schafweide.org
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
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? -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Am 19.06.2015 um 19:30 schrieb Bjoern Franke:
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.
Du willst einen nicht-gluon branch im siteconf-repo?
Ne blöde Idee :D das wäre eine sehr sehr unschöne Lösung. LG Tarek
Am 19.06.2015 um 20:06 schrieb Jan-Tarek Butt:
Am 19.06.2015 um 19:30 schrieb Bjoern Franke:
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.
mäddels ^^^ zwar kein TOFU aber TUFO https://wiki.nordwest.freifunk.net/mailingliste#A.22Richtiges.22_Zitieren_-_... bitte email programme einstellen und lassen ;-/ -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
Am Samstag, den 20.06.2015, 09:08 +0200 schrieb picard:
mäddels ^^^ zwar kein TOFU aber TUFO https://wiki.nordwest.freifunk.net/mailingliste#A.22Richtiges.22_Ziti eren_-_TOFU
bitte email programme einstellen und lassen ;-/
Wie meinen? K9-Mail kann entweder TOFU oder TUFO. -- xmpp bjo@schafweide.org
On 20.06.2015 13:30, Bjoern Franke wrote:
Am Samstag, den 20.06.2015, 09:08 +0200 schrieb picard:
mäddels ^^^ zwar kein TOFU aber TUFO https://wiki.nordwest.freifunk.net/mailingliste#A.22Richtiges.22_Ziti eren_-_TOFU
bitte email programme einstellen und lassen ;-/
Wie meinen? K9-Mail kann entweder TOFU oder TUFO.
Ich finde das auch echt nicht schlimm. Vernünftige Clients blenden Zitate schließlich aus. Wenn ich mal schnell antworten will und es ein Full-Quote wird, finde ich das alle mal besser als keine Antwort. Solche (meiner Meinung nach überflüssigen) Regeln schrecken neue Leute eher vom Mitmachen ab. -- Viele Grüße, Simon
Am 20.06.2015 um 13:43 schrieb Simon Kurka:
On 20.06.2015 13:30, Bjoern Franke wrote:
Am Samstag, den 20.06.2015, 09:08 +0200 schrieb picard:
mäddels ^^^ zwar kein TOFU aber TUFO https://wiki.nordwest.freifunk.net/mailingliste#A.22Richtiges.22_Ziti eren_-_TOFU
bitte email programme einstellen und lassen ;-/
Wie meinen? K9-Mail kann entweder TOFU oder TUFO.
Ich finde das auch echt nicht schlimm. Vernünftige Clients blenden Zitate schließlich aus. Wenn ich mal schnell antworten will und es ein Full-Quote wird, finde ich das alle mal besser als keine Antwort. Solche (meiner Meinung nach überflüssigen) Regeln schrecken neue Leute eher vom Mitmachen ab.
+1
Ich finde das auch echt nicht schlimm. Vernünftige Clients blenden Zitate schließlich aus. Wenn ich mal schnell antworten will und es ein Full-Quote wird, finde ich das alle mal besser als keine Antwort. Solche (meiner Meinung nach überflüssigen) Regeln schrecken neue Leute eher vom Mitmachen ab. das ist ein argument. -- gruß
Zitat von Simon Kurka <dev@simon.kurka.cc>: pic @ME https://wiki.nordwest.freifunk.net/picard
Zitat von Bjoern Franke <bjo@nord-west.org>:
Wie meinen? K9-Mail kann entweder TOFU oder TUFO. oder default nicht zittieren und dann unten auf zitat einfügen (oder so) und dann das zitat editieren.
lieber garnicht zitieren alles alles. -- gruß pic @ME https://wiki.nordwest.freifunk.net/picard
participants (6)
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
picard -
Simon Kurka -
Stefan