Add firmware configuration site.conf #146
Conversation
|
ein aufwasch, die site.mk und modules enthält einen großteil der gwünschten pakete |
|
danke! kannst du das bitte in development.json einbauen? eine neue Versionsdatei wird dann in einem nächsten Schritt gemacht... da müssen auch noch ein paar andere Sachen, wie z.b. die Versionsinformation in der Datei, das Changelog und der Generator angepasst werden außerdem: die Erklärung wirkt noch ein wenig dürftig. Mal heißt es Repository, mal site.conf. Macht das doch bitte a) allgemeiner und formuliert b) die Sachen um. z.b. "Link to your community firmware profile" oder "your community's firmware configuration file" Was wollt ihr am Ende mit diesem Eintrag machen? |
|
done. Wir wollen durch die verschiedenen site-conf repos ermitteln können welche gluon packages wie oft und wo verwendet werden. Siehe https://forum.freifunk.net/t/uebersicht-aller-site-mk-paketzusammenstellungen/13155 |
|
im Moment steht da immernoch verwirrend site.conf / repository ... usw. |
|
einen ähnlichen Vorschlag gibt es bereits: #118 großer Nachteil der vorgeschlagenen Verlinkung von site.conf: Das ganze funktioniert nicht allgemein-gültig für Freifunk Openwrt/LEDE, sondern NUR für die Communities, die Gluon-Firmware verwenden (und damit batman-adv only). Zudem scheint es (über die Jahre gesehen) auch kein einheitliches sit.conf-Format zu geben (siehe Änderungen Anfang des Jahres) Besser wäre wohl, wie in #118 beschrieben die Wifi-Settings allgemein zu beschreiben und ggf. Software-Zusatzpakete darüber hinaus noch zu erwähnen.. |
|
118 geht ja nur um die Wifi Settings, die benutzten Pakete in Gluon sind aber auch ganz anderer Natur:
Wir wollen eine gesamtübersicht der verfügbaren Pakete daraus generieren und auch statistiken erstellen, wie oft welche Module benutzt werden. Ich dachte, wenn wir einfach auf das repository, in dem die site.conf, modules,... ist, verweisen, kann man das alles automatisiert extrahieren. |
| "title": "Firmware Configuration Repository", | ||
| "type": "string", | ||
| "pattern": "^(http|https)://[A-Za-z0-9ÄÖÜäöüß\\-_\\./]+", | ||
| "description": "Link to your community firmware configuration file", |
|
gluon-exklusive Felder finde ich auch nicht so toll. Im Übrigen gibt es auch ein Feld Firmware Docs, was für einen entsprechenden Link genutzt werden könnte. |
|
docs klilngt aber eher nach anleitungen ;) |
|
mittlerweile fände ich gluon-exclusive Felder toll, es ist besser als nichts! |
|
Versioning gibt es schon, aber nicht standardisiert. |
|
nicht alle Gluonner sind bei github, einige haben zb auch gitlab :-o zb https://gitlab.com/FreifunkChemnitz/site-ffc/blob/chemnitz/site.conf |
|
@FreifunkUFO: Ich will hier die URL zur gluon site.conf sammeln, also ist der titel dieses PRs doch korrekt, oder? Die url hat auch nichts mit github zu tun, oder was meinst du? Ich habe das so allgemein wie möglich gefasst, damit jede auch nicht-gluon- community dort etwas sinnvolles eintragen kann. Anhand des wertes in "Firmware Name" kann man dann ja sehen ob das gluon ist oder nicht. Was meinst du sollte ich hier noch genau ändern? |
|
Wie ist der Status hier? wurde dahingehend schon was eingebaut inzwischen? Die übersicht der gluon site configs ist ja inzwischen ins Wiki gewandert: https://github.com/freifunk-gluon/gluon/wiki/Site-Configurations Ich habe site-conf-scraper gebaut, der darauf baut: https://github.com/rubo77/site-conf-scraper Allerdings ist in einigen der sites nicht automatisch ermittelbar, welches der aktive branch ist |
|
@rubo77 cooles kleines Script, hast Du da. Nie war es so leicht sich alle Firmware-Repos herunterzuladen. Schade dass die ganzen Site-URLs dort statisch definiert sind. Ich setze gerade ein Qualitätsmonitoring für die Freifunk Community Registry (directory.json) inkl. aller referenzierten Community API Dateien. Es wäre mir ein leichtes, eine firmware-site.json zu generieren, die Du dann verwenden könntest. Siehe auch: freifunk/directory.api.freifunk.net#579 Interesse? |
|
Bzgl. des eigentlichen Themas dieses PRs: Die Community API Datei dient in erster linie zum maschinellen Verarbeiten von Informationen. Immerhin muss dieses Feld ja von jemanden gepflegt werden, sowas veraltet gerne mal (wird vergesse). Macht das Sinn zu pflegen? Würde ein link auf das Firmware-Repo nicht reichen? Kann man die Datei vielleicht per Namenskonvention (Location) ggf. leicht automatisiert ermitteln? Ansonsten blasen wir uns die API mit zig "nice to have"- oder "firmware-specific"-Feldern auf. JustMy2Ct |
Ja gerne, Ich habe dich als collaborator in meinem repo geadded, vielleicht kannst du es da einfach einbauen, (hab grad wenig zeit, bin gerade in Elternzeit) |
|
@rubo77 können wir Deinen Pull Request vielleicht in diesem Monat über die Ziellinie bringen? |
ja an einen link hatte ich gedacht, was fehlt denn noch um diesen PR anzunehmen? |
|
Was noch fehlt: "This branch has conflicts that must be resolved" |
|
Kann die nötigen Anpassungen hier eventuell jemand übernehmen? Ich bin etwas raus leider seit ein paar Jahren |
No description provided.