Die Meinung darfst Du haben und sowohl äußern wie für Dich behalten. Letzteres wäre aus Respekt von anderen Firmwarebauern etwas dezenter, denn die, die lokale Änderungen nutzen, werden sich – prinzipbedingt mehr als pull-build-publish-Anhänger – ihre Gedanken gemacht haben, denn das macht massiv Arbeit.
You have the source to do that; wir hatten hier schon wiederholt die Thematik der ›Zusammenarbeit‹ via PR, und daß dies bei unterschiedlichen Auffassungen schnell kracht. Ich für meinen Teil habe weder Lust auf blutige Diskussionen über Sinn oder Unsinn von Krümmungsfaktoren von Gurken noch Zeit, über die Positionen von Spaces oder Klammern zu diskutieren. Da es anderen ähnlich geht, nur vielleicht Lust und Zeit verdreht, ist für mich der Fork die logische Konsequenz. YMMV, aber das erhebt eine andere Meinung nicht in eine ›richtigere‹ Position.
Edit: beim Erstellen versehentlich wieder in Radevormwald gestellt, sollte aber eine Ebene höher; sorry & fixed.
Ach, wer braucht schon eine Off-Line-SSID oder einen Hoodselector.
Wenn auch nach 4(?) Jahren keine PRs akzeptiert wurden, dann kann soetwas doch nichts taugen, ist politisch extrem unerwünscht oder völlig überflüssig.
Man muss meiner Meinung nicht sofort im Stable Zweig der eigenen Firmware die allerneueste Gluon Version ausrollen. Sofern man sich dadurch halt nicht einen Vorteil verspricht. Aber man kann ja auch durchaus noch andere Zweige anlegen.
Also zum Beispiel Experimental oder Nightly. Denn dann kann man besser frühzeitig auf mögliche Probleme reagieren.
Bezüglich Community spezifischen Änderungen wurde ja vor kurzem zum Beispiel das community-packages Repository angelegt. Da könnte man also zum Beispiel dort gemeinsam Pakete entwickeln.
Ich würde aber schon versuchen nicht zu weit hinter die aktuelle Version zurückzufallen. Denn sollte es Mal eine kritischere Sicherheitslücke geben wird es sicherlich eine gepatchte Version für die letzte Majorversion geben, aber das Gluon 2014 oder 2015 noch einen Patch bekommt ist eher Mal unwahrscheinlich.
Und ganz allgemein: Wenn der Berg zu groß wird bekommt man meistens die größten Probleme.
Welch schöne Polemik.
Teile des Hoodselector sind doch längst integriert?
Und bei den PRs zum Thema „offline ssid“ ist die Beteiligung mau - und hier nehme ich mich selbst mit in die Pflicht, denn da wir in der community auch ähnliches nutzen, sollte ich selbst mich auch mehr darum kümmern…
Aber vor allem letzteres braucht keinen fork, da es als Package einbindbar ist
Wir hatten dieses sehr nützliche Package auch bei uns in der Firmware. Nun ist es wieder rausgeflogen, weil es kein „offizielles“ Package von Gluon sei.
Dann bau ich mir halt für meine Knoten eine eigene Firmware. Ist zwar schade, aber das geht ja auch - Gluon sei Dank.
Auch solche Packages wollen gepflegt werden und stehen ggf. beim Bau von »master« im Weg, wenn sie nicht parallel mit überarbeitet werden. Insofern kann ich das beschriebene Vorgehen nachvollzehen; andererseits sollte einer Firmware ja auch ein »Pflichtenheft« aus der Community gegenüberstehen, sprich: was soll die FW können? Da finde ich FF_OFFLINE sowohl sinnvoll, um »ach, Freifunk tut doch eh’ nicht« entgegenzuwirken, als auch zur Ferndiagnose (»Sie finden keine Freifunk-SSID? Sehen Sie denn eine mit »offline« im Namen?«).
