\o/ Das ändert einiges :) vg Tarek -------- Forwarded Message -------- Subject: [gluon] [ANNOUNCE] Gluon v2016.1 Date: Mon, 8 Feb 2016 11:16:50 +0100 From: Matthias Schiffer <mschiffer@universe-factory.net> To: gluon@luebeck.freifunk.net CC: Freifunk Firmware Entwicklung <firmware-devel@freifunk.net>, WLANware <wlanware@freifunk.net> Hi, I'm happy to announce that Gluon v2016.1 has finally landed! As you've already noticed, this has taken a lot longer than planned. The change from Barrier Breaker to Chaos Calmer had caused some unexpected instabilities which had to be addresses before making this release. The release notes can be found at https://gluon.readthedocs.org/en/v2016.1/releases/v2016.1.html Please read the "Site changes" section very carefully, as there have been lots of changes. You might even want to re-read the "Getting started" guide to find out about our new kernel module opkg repo feature. We thank all our contributors, who have helped us with code [1], bug reports, testing or just participating in discussions in our issue tracker or on IRC. Regarding release frequency, 2015 hasn't been our most lucky year. We hope to improve on that in the future and get back to a more regular release schedule. -- NeoRaider [1] https://github.com/freifunk-gluon/gluon/graphs/contributors
Hi,
Hi, I'm happy to announce that Gluon v2016.1 has finally landed!
As you've already noticed, this has taken a lot longer than planned. The change from Barrier Breaker to Chaos Calmer had caused some unexpected instabilities which had to be addresses before making this release.
Das ist zwar jetzt sehr kurzfristig aber es war ja auch nicht abzusehen wie lange gluon2016.1 noch brauchte. Im grunde könnten wir 0.6.3 und 0.7.1 nun verwerfen und direkt auf 0.8 mit gluon2016.1 wechseln somit brauchen wir die aktuellen testing router die auf stable zeigen u.a. die v10 modelle nicht erst wieder auf den testing branch um switchen sondern können die direkt auf gluon2016.1 stable hochziehen. und mit 8.1 könnte dann auch direkt der hoodselector folgen sobald der alles testcases bestanden hat. Meinungen ? vg Tarek
+1 Moin Würde den Release Prozess auf jedenfall entzerren und einfacher machen. Mit 0.8 hätten damit ja alle Router den selben Stand. Und man kann sauber weitermachen. Ich wäre dafür Gruß Johannes Von meinem iPhone gesendet
Am 08.02.2016 um 13:46 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Hi,
Hi, I'm happy to announce that Gluon v2016.1 has finally landed!
As you've already noticed, this has taken a lot longer than planned. The change from Barrier Breaker to Chaos Calmer had caused some unexpected instabilities which had to be addresses before making this release.
Das ist zwar jetzt sehr kurzfristig aber es war ja auch nicht abzusehen wie lange gluon2016.1 noch brauchte.
Im grunde könnten wir 0.6.3 und 0.7.1 nun verwerfen und direkt auf 0.8 mit gluon2016.1 wechseln somit brauchen wir die aktuellen testing router die auf stable zeigen u.a. die v10 modelle nicht erst wieder auf den testing branch um switchen sondern können die direkt auf gluon2016.1 stable hochziehen. und mit 8.1 könnte dann auch direkt der hoodselector folgen sobald der alles testcases bestanden hat.
Meinungen ?
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Montag, 8. Februar 2016, 13:46:41 CET schrieb Jan-Tarek Butt via Dev:
Im grunde könnten wir 0.6.3 und 0.7.1 nun verwerfen und direkt auf 0.8 mit gluon2016.1 wechseln somit brauchen wir die aktuellen testing router die auf stable zeigen u.a. die v10 modelle nicht erst wieder auf den testing branch um switchen sondern können die direkt auf gluon2016.1 stable hochziehen.
Hört sich gut an. Ich würde die 0.8 trotzdem gut testen, denn Gluon 2016.1 bringt zahlreiche Änderungen mit sich und die Known-Issues-Section sieht für mich auf den ersten Blick auch nicht ganz ohne aus. Insgesamt ein schöner Zeitgewinn für uns und vielleicht hat der ein oder andere aus diesem Chaos ja auch etwas mitgenommen ohne dass uns das jetzt zu Tode nervt. Viele Grüße Clemens
On 02/08/16 14:11, Clemens John via Dev wrote:
Am Montag, 8. Februar 2016, 13:46:41 CET schrieb Jan-Tarek Butt via Dev:
Im grunde könnten wir 0.6.3 und 0.7.1 nun verwerfen und direkt auf 0.8 mit gluon2016.1 wechseln somit brauchen wir die aktuellen testing router die auf stable zeigen u.a. die v10 modelle nicht erst wieder auf den testing branch um switchen sondern können die direkt auf gluon2016.1 stable hochziehen.
Hört sich gut an.
Ich würde die 0.8 trotzdem gut testen, denn Gluon 2016.1 bringt zahlreiche Änderungen mit sich und die Known-Issues-Section sieht für mich auf den ersten Blick auch nicht ganz ohne aus.
Keine frage, Da stimme ich dir zu. Ich werde erst mal im master soweit alles für gluon2016.1 vorbereitet. Es herrscht auch aktuell bei allen Routern die openWRT CC installiert haben eine Sicherheitslücke. https://dev.openwrt.org/changeset/48373
Insgesamt ein schöner Zeitgewinn für uns und vielleicht hat der ein oder andere aus diesem Chaos ja auch etwas mitgenommen ohne dass uns das jetzt zu Tode nervt.
Wir gewinnen gut zwei Wochen dadurch :) Ich konnte einiges an neuen Erfahrungen mitnehmen. vg Tarek
Hab gerade gelesen, dass das Meshing dann anders läuft, hat das Nachteile für uns? Vorteil ist ja ein breiteres Feld an kompatibler Hardware. Mit freundlichen Grüßen Jens Ellerbrock -------------------- Freifunk Nordwest e.V. Website Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Am 08.02.2016 um 14:25 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
On 02/08/16 14:11, Clemens John via Dev wrote: Am Montag, 8. Februar 2016, 13:46:41 CET schrieb Jan-Tarek Butt via Dev:
Im grunde könnten wir 0.6.3 und 0.7.1 nun verwerfen und direkt auf 0.8 mit gluon2016.1 wechseln somit brauchen wir die aktuellen testing router die auf stable zeigen u.a. die v10 modelle nicht erst wieder auf den testing branch um switchen sondern können die direkt auf gluon2016.1 stable hochziehen.
Hört sich gut an.
Ich würde die 0.8 trotzdem gut testen, denn Gluon 2016.1 bringt zahlreiche Änderungen mit sich und die Known-Issues-Section sieht für mich auf den ersten Blick auch nicht ganz ohne aus.
Keine frage, Da stimme ich dir zu. Ich werde erst mal im master soweit alles für gluon2016.1 vorbereitet. Es herrscht auch aktuell bei allen Routern die openWRT CC installiert haben eine Sicherheitslücke. https://dev.openwrt.org/changeset/48373
Insgesamt ein schöner Zeitgewinn für uns und vielleicht hat der ein oder andere aus diesem Chaos ja auch etwas mitgenommen ohne dass uns das jetzt zu Tode nervt.
Wir gewinnen gut zwei Wochen dadurch :) Ich konnte einiges an neuen Erfahrungen mitnehmen.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
On 02/08/16 15:02, Jens Ellerbrock - Freifunk Nordwest e.V. via Dev wrote:
Hab gerade gelesen, dass das Meshing dann anders läuft, hat das Nachteile für uns? Vorteil ist ja ein breiteres Feld an kompatibler Hardware.
Das ist im Grunde das IEEE802.11s das Werden wir bei uns allerdings noch nicht mit rein nehmen da viele tools wie iwlist usw. das IEEE802.11s noch nicht ermitteln können und das ist bei uns zwingende Voraussetzung für den Einsatz mit hoods. schöne Grüße Tarek
Ok,Mann müssen wir nur aufpassen, das keine Firmware erstellt wird, für Geräte die nur IEEE802.11s können! Werden demnächst ein paar zu Gluon kommen. Mit freundlichen Grüßen Jens Ellerbrock -------------------- Freifunk Nordwest e.V. Website Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten)
Am 08.02.2016 um 15:45 schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
On 02/08/16 15:02, Jens Ellerbrock - Freifunk Nordwest e.V. via Dev wrote: Hab gerade gelesen, dass das Meshing dann anders läuft, hat das Nachteile für uns? Vorteil ist ja ein breiteres Feld an kompatibler Hardware.
Das ist im Grunde das IEEE802.11s das Werden wir bei uns allerdings noch nicht mit rein nehmen da viele tools wie iwlist usw. das IEEE802.11s noch nicht ermitteln können und das ist bei uns zwingende Voraussetzung für den Einsatz mit hoods.
schöne Grüße Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hey geil :) Was schätzt ihr, wann könnte vom reinen Zeitplan die erste hood laufen? Am 8. Februar 2016 15:45:27 MEZ, schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
On 02/08/16 15:31, Simon Kurka wrote:
+1 yeeeehaaaaa
;P
------------------------------------------------------------------------
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan
Ja okay. Wie sieht es denn serverseitig aus und benötigt ihr noch Hilfe? Sind die Tunnel beim Rheinland schon beantragt? Am 8. Februar 2016 18:58:46 MEZ, schrieb Jan-Tarek Butt via Dev <dev@lists.ffnw.de>:
Was schätzt ihr, wann könnte vom reinen Zeitplan die erste hood laufen?
Im Moment würde ich sagen dann wenn es fertig ist.
Es ist zeitlich nicht wirklich abschätzbar zumindest für mich nicht. Denn ich weiß nicht was serverseitig noch alles gemacht werden muss.
vg Tarek
------------------------------------------------------------------------
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan
Du kannst gerne einen Code-Review der Module in https://github.com/ffnw/ machen. Ich habe die bisher nur so heruntergeschrieben. Die Ausführung steht noch aus. Jedes mal wenn ich Zeit habe schreibe ich an weiteren Modulen und lade sie hoch. Da kommt also noch ein bisschen was... Am 08.02.2016 19:03 schrieb "Stefan via Dev" <dev@lists.ffnw.de>:
Ja okay.
Wie sieht es denn serverseitig aus und benötigt ihr noch Hilfe? Sind die Tunnel beim Rheinland schon beantragt?
Am 8. Februar 2016 18:58:46 MEZ, schrieb Jan-Tarek Butt via Dev < dev@lists.ffnw.de>:
Was schätzt ihr, wann könnte vom reinen Zeitplan die erste hood laufen?
Im Moment würde ich sagen dann wenn es fertig ist.
Es ist zeitlich nicht wirklich abschätzbar zumindest für mich nicht. Denn ich weiß nicht was serverseitig noch alles gemacht werden muss.
vg Tarek
------------------------------
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Ich mache dafür mal nen neuen Thread auf.... On 02/08/16 19:23, Simon Kurka via Dev wrote:
Du kannst gerne einen Code-Review der Module in https://github.com/ffnw/ machen. Ich habe die bisher nur so heruntergeschrieben. Die Ausführung steht noch aus.
Jedes mal wenn ich Zeit habe schreibe ich an weiteren Modulen und lade sie hoch. Da kommt also noch ein bisschen was...
Simon magst du die Module in gitlab umziehen? Ich halte es nicht wirklich für sinnvoll jetzt noch eine dritte Gruppe bei github auf zu machen. vg Tarek
Ich ziehe das nicht um, da viele Module allgemein verwendbar sind und es meiner Meinung nach eine Illusion ist, dass andere in das ffnw interne gitlab schauen. Wer es sich lieber in Gitlab ansieht möge sich bitte um einen clone + regelmäßiges pullen bemühen. Am 08.02.2016 20:40 schrieb "Jan-Tarek Butt via Dev" <dev@lists.ffnw.de>:
Ich mache dafür mal nen neuen Thread auf....
On 02/08/16 19:23, Simon Kurka via Dev wrote:
Du kannst gerne einen Code-Review der Module in https://github.com/ffnw/ machen. Ich habe die bisher nur so heruntergeschrieben. Die Ausführung steht noch aus.
Jedes mal wenn ich Zeit habe schreibe ich an weiteren Modulen und lade sie hoch. Da kommt also noch ein bisschen was...
Simon magst du die Module in gitlab umziehen?
Ich halte es nicht wirklich für sinnvoll jetzt noch eine dritte Gruppe bei github auf zu machen.
vg Tarek
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Ich ziehe das nicht um, da viele Module allgemein verwendbar sind und es meiner Meinung nach eine Illusion ist, dass andere in das ffnw interne gitlab schauen.
Wer es sich lieber in Gitlab ansieht möge sich bitte um einen clone + regelmäßiges pullen bemühen.
Aber das ist doch quatsch an x verschiedenen orten repos von Freifunk Nordwest haben. Da steigt doch auch niemand mehr durch. Die mehrheit hat sich damals für gitlab entschieden. Ich wäre im Nachhinein auch viel lieber bei gitphp geblieben. Wir könnten ja die Repos zu github mirrorn dann kann jeder in github die repos ein sehen obwohl es auch jeder in gitlab einsehen kann. Falls das auch nicht gewünscht ist. Wäre ich zumindest froh darum wenn du die ffnw Organisation in die FreifunkNordwest Organisation auf github migrierst. https://github.com/FreifunkNordwest vg Tarek
Am Montag, 8. Februar 2016, 21:59:36 CET schrieb Jan-Tarek Butt via Dev:
Aber das ist doch quatsch an x verschiedenen orten repos von Freifunk Nordwest haben. Da steigt doch auch niemand mehr durch. Die mehrheit hat sich damals für gitlab entschieden. Ich wäre im Nachhinein auch viel lieber bei gitphp geblieben. Wir könnten ja die Repos zu github mirrorn dann kann jeder in github die repos ein sehen obwohl es auch jeder in gitlab einsehen kann.
Hi, ich sehe das ganz genau so wie Tarek und lehne eine Entwicklung an verschiedenen Orten ab. Wir haben die Diskussion mehrmals mit dem selben Ergebnis geführt und ich sehe keine Notwendigkeit für eine erneute Diskussion. Die Gegebenheiten haben sich nicht geändert. Ich verstehe ja, dass jeder seine Freizeitprojekte am liebsten an dem Ort hostet, den er subjektiv für den besten hält. In einem Team gehört es jedoch dazu sich gemeinsam an die getroffenen Vereinbarungen zu halten, auch wenn diese nicht den subjektiven Wünschen entsprechen. Das ist manchmal schmerzlich aber jeder kann damit einen einfachen Beitrag für einen guten Projektverlauf leisten. Was passiert, wenn sich die Beteiligten nicht an die getroffenen Vereinbarungen halten, haben wir gerade erst gesehen als eine relativ große Gruppe gegen jede Empfehlung testing Firmware produktiv eingesetzt hat. Das führt bei allen Beteiligten zu Unmut und massivem Mehraufwand. Wenn ihr Tools außerhalb von Freifunk Nordwest entwickelt, dann hostet die gerne bei Github, Bitbucket oder Sourceforge. Aber wenn ihr Tools hier im Team unter Nutzung der Ressourcen dieses Teams entwickelt, dann nutzt bitte auch unser gemeinsames Projektmanagementsystem als Primärquelle und spiegelt die Resourcen, wenn ihr sie gerne zusätzlich an einem anderen Ort verfügbar machen möchtet. Damit wird das Leben allen Beteiligten sehr vereinfacht. Viele Grüße Clemens
participants (6)
-
Clemens John -
Jan-Tarek Butt -
Jens Ellerbrock - Freifunk Nordwest e.V. -
Johannes Rudolph -
Simon Kurka -
Stefan