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
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
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.
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?
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 ;-/
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.
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.
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
Zitat von Simon Kurka dev@simon.kurka.cc:
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.
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.
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
picard -
Simon Kurka -
Stefan