Vorab erstmal vielen Dank an alle Beteiligten für die Arbeit an dem Gluon-Release v2020.1.x!
Damit die lokalen Firmware-Bauer keine unnötige Analyse-Zeit wegen Anfragen aus ihrer Community aufwenden müssen, und diese Zeit besser zur gemeinsamen Verbesserung von Gluon genutzt werden kann, anbei einige bereits bekannte Auffälligkeiten zu Gluon v2020.1.x:
TP-Link TL-MR3020 starten nicht mehr als FF-Knoten auf. Anstelle dessen aktivieren die Router den Failesafe-Mode (gefixt mit Gluon v2020.1.3):
Ich verstehe den Sinn hinter diesem Thread/Wiki nicht?
Der Issuetracker von Gluon befindet sich hier: Issues · freifunk-gluon/gluon · GitHub und dieser sollte auch die Single Source of Truth sein.
Damit die lokalen Firmware Bauer und im Idealfall auch die Gluon Kontributoren keine unnötige Analyse-Zeit wegen Bugsuche in mehreren Foren Threads aufwenden müssen, und diese Zeit besser zur gemeinsamen Verbesserung von Gluon genutzt werden kann, sollten dort auch möglichst alle Bugs gesammelt werden.
Vor dem Wechsel auf einen neuen Gluon Branch sollte das auf jeden Fall eine der Stellen sein die man nach den Release Notes zusätzlich checkt.
Wenn das hier für dich ein Bug ist, würde ich mich freuen wenn wir demnächst im Issue Tracker ein einen entsprechenden Bugreport sehen würden.
Danke, herrbett.
Ergänzend sei gesagt, dass alle fünf bisher hier genannten „Auffälligkeiten“ nicht direkt in Gluon sind, sondern von OpenWrt oder batman-adv.
Die Einstellung „ist upstream-issue, geh’ weg“ ist vielleicht der Grund, warum der Thread hier ist. (abgesehen davon, dass nicht jedes Problem auch ein Issue ist, sondern evtl. auch eine Verständnisfrage mit der man nicht gleich einen Bug unterstellen möchte)
Und Leute eben auch absichtlich keine Gluon-Issues bei Schwierigkeiten aufmachen, weil sie diese Antwort bereits kennen und ihnen dann nicht weiterhilft (die wenigsten mögen mit einem lokalen Freifunk-Background in das Openwrt-Haifischbecken springen.)
Oder anders formuliert:
Da man bei der Nutzung von Gluon kaum einen Einfluss auf Kernel oder Openwrt hat (bei Batman):
Ergibt keinen Unterschied, ob ein unerwartetes Verhalten nun „Upstream issue“ ist oder nicht, da die Auswahl der Komponenten seitens der Openwrt-Maintainer getroffen wurde.
Ich zitiere mal aus dem Thread zur Archer C7 Problematik auf eurer Liste, das Problem mit dem Upstream melden war dort nämlich definitiv anders gelagert.
ich bin dem Link gefolgt und habe dabei festgestellt, daß ich dafür ein Github-Zugang benötige über den ich nicht verfüge.
Auch wenn ich mich nun registrieren würde, habe ich die Schwierigkeit mit dem Erstellen des Issues und die entsprechenden Informationen zu liefern, da ich von dem Firmware bauen keinerlei Ahnung habe.
Im Endeffekt ist es eure Entscheidung ob ihr die Bugs bei Gluon einkippt, die Klassifizierung wo der Bug herkommt ist für uns jedenfalls entscheidend dafür ob wir direkt etwas unternehmen können.
Dein zitierter Text ist etwas aus dem Zusammenhang gerissen.
Nachdem der Freifunker das Verhalten erstmalig auf unserer Mailingliste gepostet hatte, kam auf gefolgt die knappe Antwort, dass er doch bitte ein Gluon-Issue aufmachen solle.
Erst daraufhin hat der Freifunker dann die von Dir zitierte Nachricht geschrieben.
Aber darum geht es hier auch gar nicht.
Sinn dieses Threats war es jeden Falls nicht, irgendwenn in die Rechtfertigungsecke drücken zu wollen. Wenn der Eindruck entstanden ist, dann entschuldige ich mich dafür.
Es geht eher darum, dass Communitys und Node-Aufstellern, welche bereits ihre eigene Firmware auf Gluon v2020.1 umgestellt haben, niederschwelliege Informationen an die Hand gegeben bekommen können. Hiermit könnten mehrfach erste durchgeführte Analyse-Aufwänd reduziert und vermieden werden, besonders für z.B. aktive Freifunker, welche sich alleinig nur hier im Forum aufhalten.
P.S.
Um dann doch nochmal auf das „Beispiel“ der C7-v2-Problematik zurück zu kommen. Letztendlich wurde innerhalb aller kürzester Zeit das Problem gemeinsam angegangen und gelöst.
Danke dafür an die Gluon-Entwickler.
@hexa
Ich denke wir reden evtl. leicht aneinander vorbei.
Für den lokalen Freifunker mit Router-Problemen ist die erste Anlaufstelle erstmal die Community. Und dort wurde er dann bei uns direkt auf „upstream“ zu Gluon verwiesen.
Upstream ist eben relativ. Selbst Upstream hat einen Upstream, hat einen Upstream, hat einen…
Wir hatten das Thema doch schon so oft… Wir sind alle freiwillige, und da wird auch von einem Problemmelder Aktivität gefordert, einer All-Inclusive Erwartungserhaltung steht jeder Ehrenamtliche/Freiwillige allergisch gegenüber.
Aber am Ende hast du mich sowieso falsch verstanden, ich wollte das Thema gar nicht in diese Richtung bewegen sondern nur deutlich machen, dass dies keine Gluon Auffälligkeiten sind in dem Sinne, dass sie Gluon-spezifisch wären. Diese Punkte betreffen auch jede andere (Freifunk-)Firmware auf Basis von OpenWrt 19.07 zum Zeitpunkt der Thread-Eröffnung.
Was möchtest Du denn damit argumentieren?
Ist Dein Punkt, dass dieser Thread hier geschlossen werden sollte, weil es unstatthaft ist, hier Dinge zu Gluon zu diskutieren, die Leuten auffallen?
Noch mal zur Vergegenwärtigung: Es wurde gefragt, „warum hier und nicht direkt issues in Gluon aufmachen“: „Weil Einstiegshürde niedriger und Leute es nicht unfallfrei hinbekommen, die Erfordernisse eines Git-Issues zu erfüllen“
Dann kam die Frage „was soll daran schierig sein, das ist doch ganz einfach“
Darauf die Erläuterung, wie die Mechaniken mit „Upstream vom Upstream vom Upstream“ für Neulinge aussehen und dass es ohne Vermittlung erfahrener Menschen schwierig ist.
Da jetzt die Karte „eingeschnappt“ zu ziehen („Aber wir sind doch freiwillig hier, ihr wisst unsere Arbeit nicht zu schätzen“): Kann man machen, ist aber nicht zielführend dafür, dass es schlicht darum geht, Leuten ermöglichen soll, unvoreingenommen ihre Beobachtungen zu reporten. Eben gerade OHNE daraus sofort eine „Ist ein Bug“-Unterstellung zu formulieren.
Vielleicht sollte man sich vorher mal an die eigene Nase Fassen.
Wie ein Bug gefunden wird und wer daran beteiligt ist, ist zweitrangig… Das kann im Forum, genauso passieren wie auf Mailinglisten oder Lokal auf Freifunk Treffen.
Wichtig ist das diese Bugs an die richtigen Stellen kommuniziert werden. Und das ist nun mal kein Foren Thread, sondern der Issue Tracker in Github.
Von mir aus sehe ich es ein das es für manche zu schwer ist dort ein Issue zu öffnen, das hindert aber nicht die Community die den Bug gefunden hat daran ein wenig Hilfestellung zu leisten. Zu zweit geht vieles deutlich Leichter. Wenn wir im Forum über Bugs Pöbeln müssen ist niemanden geholfen und wir haben alle unsere Freizeit verschwendet.
Selbst wenn es sich dann rausstellt das der Bug weiter Upstream behoben werden muss, erst mal freundlich Melden und drauf hinweisen das etwas nicht geht, gemeinsam nach der Ursache suchen, und im Zweifel das Problem an das nächste Projekt weiterreichen…
Ich sehe in hier hauptsächlich eine Möglichkeit die für Gluon 2020.1 relevanten Issues aus den 95 Issues die es für Gluon aktuell gibt herauszufiltern und kurz übersichtlich dazustellen.
Dafür ist es doch gut. Alles andere sollte aber natürlich über Gluon Issues geregelt werden.
Aber all das was Du beschreibst, dass ist doch zeitgleich freundlich passiert.
Bis auf zwei Meldung habe ich bei der Kommunikation der Gluon-Issues mitgewirkt. Als Fragender im IRC, und im Github als Ersteller, Log-Lieferer und Tester.
Die zwei anderen Punkte sind übrigens nur Verlinkungen „von bereits bestehend“ GitHub-Issues gewesen.
Aber nochmal, darum geht es hier überhaupt nicht.
Und noch mal zu Verdeutlichung:
Freifunker spielen eine neue Community-Firmware auf, welche bereits Gluon v2020.1 als Basis hat, und sehen, das ihr Router nicht mehr so funktioniert, wie sie es erwarten.
Wo liegt da bitte schön jetzt das Problem, dass besagte Freifunker bereits hier im Forum niederschwellig Informationen zu identischen Verhalten finden können? (Die Frage ist ernst gemeint.)
… ist ein Thread pro Release hier genau richtig, sich nach den Release Notes noch durch GitHub zu wühlen und zu rätseln, ob das bemerkte ein known issue ist, halte ich für unrealistisch.
Auch und gerade, damit die late adopters von den Erfahrungen der early adopters lernen können, macht das hier Sinn. Ob/wie das dann in ein Issue wandert, ist eine vollkommen andere Thematik. Ohne jenes gibt’s eher keine Abhilfe, ist dann halt so.
Zudem: Issue-Tracker sind eher schlechte Diskussionstools, schnell wird jemand ob der Nachrichtenflut meckern.
Bislang waren wir hier ja eher auf der Schiene „was für Effekte gibt es in Gluon2020, mit denen vielleicht nicht rechnen konnte“
(aka: „Dinge, die man bugs sind oder die man dafür halten könnte“)
Umgekehrt:
Welche erkennbaren positiven Unterschiede gibt es denn bei Gluon 2020 gegenüber 2019, abgsehen von den „mehr supported Hardware“ und „Kernel mit höherer Versionsnummer=evtl fast immer besser“.
Konkret würde mich interessieren, wie sich die real-world-Performance evtl. verändert hat, z.B. in Perspektive auf die verschiedenen(!) Auslastungs/HighClientcount/Speicherdruck-Probleme der Vergangenheit.
Ich habe oben im OP mal ein Dokument verlinkt, nach dem man ohne serielles Interface (aber trotzdem mit zwingend notwendigem physischen Zugriff) einen UBNT EdgeRouter X (X-SFP) sicher von Gluon v2019.x (oder älter) auf Gluon v2020.1 (oder neuer) aktualisieren kann.
