Berich vom Freifunk Franken Mumble am 21.05.2019

[Robert Langhammer]

Hallo, 

ich denke nicht, daß die Mailingliste der Grund für den schleppenden Review Prozess ist. Oder dass es auf Github und Co. besser wird. Die Kommunikation via Mail ist doch eine der einfachsten. Jeder kann sich beteiligen. Aber da kommt nix. 
Ich denke, es liegt daran, daß sich viele nicht befähigt fühlen mitzureden. Und das würde sich nicht ändern, wenn man auf github über PRs diskutiert. 

Es ist meines Erachtens kein technisch zu lösendes Problem. Wir sollten versuchen interessierte Leute zu ermutigen sich zu beteiligen und evtl. ein Angebot machen, um die ersten Hürden zu nehmen. Der Umgang mit der ML ist da sicher eine der kleinsten. 

Also Leute, habt keine Scheu und fragt einfach mal nach, was der eine oder andere Patch soll, falls es dich interessiert. Jeder, der einen Patch einreicht, freut sich über Rückmeldungen jeder Art. Schlimm ist es, wenn nicht eine Antwort kommt. 

Grüße 
Robert 




Am 21. Mai 2019 22:21:33 MESZ schrieb lemmi <lemmi at nerd2nerd.org>:
>Hallo,
>
>am Dienstag 21.05.2019 fand das Freifunk Franken Mumble statt. Weil die
>
>Themen hauptsächlich die Firmwareentwicklung bzw. Entwicklung allgemein
>
>betrafen, gibt es hier nochmal eine Zusammenfassung und Ergänzungen zur
>
>Mitschrift im Pad:
>
>https://pad.freifunk.net/p/fffcommunity
>
>
>    Überarbeitung der Monitoring API
>
>Es geht hierbei hauptsächlich um das Format, wie die Daten an das 
>Monitoring übertragen werden sollen.
>
>  * https://github.com/FreifunkFranken/fff-monitoring/issues/197
>  * https://github.com/FreifunkFranken/fff-monitoring/issues/198
>
>Aktuell haben wir ein etwas undurchsichtiges, undokumentiertes aber zum
>
>Glück noch funktionierendes xml-in-json, was aus Alfred gezogen an das 
>Monitoring geschickt wird.
>
>Um gleich mehrere Fliegen mit eine Klappe zu schlagen ist der aktuelle 
>Schlachtplan der folgende:
>
>1. Definition eines Json-Schemas
>      * https://json-schema.org/
>      * Diskussion: https://pad.f3netze.de/p/nodewatcher
>      * Direkt Dokumentieren (Json-Schema sieht dafür Kommentar und
>        Beschreibungsfelder vor)
>2. Neuer Test Endpunkt für das Monitoring
>      * Parser sollte vollständig aus dem Schema generiert sein
>3. Testclients
>      * Sollten ebenfalls mithilfe von Codegeneratoren gebaut sein
>      * Zum testen kann man seine Daten mit dem Schema validieren
>      * https://app.quicktype.io/
>4. Nodewatcher überarbeiten
>      * wunsch nach modularisierung, bsp. könnten Batman, Babel, usw.
>        eigene Module sein, die man an und abschalten kann.
>5. In die Firmware integrieren
>6. Alten Endpunkt abschalten
>
>Es sollte klar sein, dass gerade die letzten beiden Punkte weit in der 
>Zukunft liegen. Das heißt aber nicht, dass der Rest nicht in den 
>nächsten Monaten passieren kann.
>
>Sobald ich kann, werde ich mal einen ersten Vorschlag zu einem Schema 
>machen und dann können wir auch gerne darüber hier in der Mailingliste 
>diskutieren.
>
>
>    Gatewayfirmware
>
>Fabians Arbeit an der "Gatewayfirmware" soll in die offizielle Firmware
>
>gemerged werden. Dazu ist noch eine Menge Reviewarbeit nötig.
>
>Bisher hat Fabian einen Teil der Patches zurückgehalten um nicht zu
>viel 
>offene Patches herumliegen zu haben. Adrian war es teilweise Lieber 
>größere Häppchen zu haben.
>
>Der Reviewprozess ist dennoch schleppend und hat daher zu folgender 
>Diskussion geführt:
>
>
>    Entwicklungsprozess
>
>Einigen ist eventuell der Entwicklungsprozess über die Mailingliste 
>nicht wirklich klar.
>
>Es kam die Frage auf, was der Unterschied zwischen "Acked-by" und 
>"Reviewed-by" ist.
>
>Generell wurden, scheinbar nicht zum ersten Mal, die potentiellen 
>Nachteile der Arbeit über die Mailingliste zusammengetragen:
>
>  * Nicht Einsteigerfreundlich
>  * Flut an (ungeordneten) Patches
>  * Man verliert leicht den Überblick (große Patches / Patchsets)
>  * Kontext schwierig zu Erkennen bei kleinen Patches
>
>Eventuell ist ein wechsel auf andere Plattformen eine Lösung:
>
>1. gitea
>      * https://gitea.io
>      * Self-hosted
>      * Habe ich persönlich am Laufen
>     * Weniger Features, aber vermutlich ausreichend für unseren Bedarf
>      * Easy Setup
>      * Wenig Resourcen nötig
>      * Benötigt wieder Accounts für alle
>2. gitlab
>      * https://about.gitlab.com/
>      * Kann man selbst Hosten
>      * dann vermutlich moderator Infrastrukturaufwand, aber noch keine
>        persönliche Erfahrung
>      * Benötigt auch wieder Accounts für alle wenn selbst gehosted
>        wird, aber vermutlich auch wenn man die Seite benutzt
>3. github
>      * Vermutlich den meisten Bekannt
>      * Repo liegt schon dort
>      * "Zentralisierung"
>          o Man kann allerdings mit webhooks viel archivieren, Beispiel
>            voidlinux:
>          o https://inbox.vuxu.org/voidlinux-github/
>       o https://github.com/leahneukirchen/gh-mailinglist-notifications
>      * Ich nehme an, dass viele schon Accounts haben
>
>Es gab dazu ein einige Detaildiskussion, aber eventuell sollten die 
>Betroffenen da selbst noch etwas dazuschreiben.
>
>
>    Entwicklertreffen
>
>Fabian wünscht sich ein regelmäßiges, persönliches Entwicklertreffen. 
>Auch um Einsteigerhilfe zu bieten. Hin und wieder könnte man Mumble zum
>
>Ausweichen verwenden.
>
>Es wurde bisher nicht geklärt wie, wo, in welchem Abstand das 
>stattfinden soll.
>
>
>So, hoffe ich habe den Großteil sinngemäß wiedergeben köennen (danke 
>Fabian fürs Mitschreiben)
>
>Grüße,
>
>lemmi