[Alternative PATCH 0/7] Alternatives Set zum OpenWrt 18.06

Di Aug 14 18:35:13 CEST 2018

Hi Tobias

Am Dienstag, den 14.08.2018, 11:30 +0200 schrieb Tobias Klaus:
> Hey Tim,
> 
> so grundsätzlich gehe ich bei Adrians Argumentation mit. Das liegt,
> aber 
> vielleicht auch einfach daran, dass er iwie konstruktiver wirkt und 
Aha.

> ich seinen 
> Lösungsansatz prinzipiell erstmal eingängiger finde. (Ich hab beide
> Patchsets 
> nur überflogen.). Auch finde ich Michaels Einlassungen bezüglich der 
> Bastelfreundlichkeit als niederschwellige "Einstiegsdroge" nicht von
> der Hand 
> zu weisen.
> 
> Ansonsten habe ich hauptsächlich noch ein paar Kommentare und Fragen
> inline.
> 
> Am Montag, 13. August 2018, 07:49:27 CEST schrieb Tim Niemeyer:
> > Hi
> > 
> > Am 12. August 2018 22:47:39 MESZ schrieb mail at adrianschmutzler.de:
> > > Hallo,
> > > 
> > > trotz einiger Bedenkzeit bin ich immer noch der Meinung, dass uns
> > > diese
> > > Lösung mehr Arbeit macht, als sie uns Vorteile bringt.
> > 
> > da hast du jetzt die beiden patchsets verwechselt. In diesem geht
> > es gerade
> > darum Arbeit und Verwirrung zu sparen.
> 
> Also falls das lustig gemeint ist, fehlt mir gerade der Humor.
> Andernfalls 
> empfinde ich solche Kommentare in einer Diskussion, in der man
> sachlich auf 
> die Argumente des anderen eingehen möchte, irgendwie deplaziert.
Nein, nicht lustig!

Ich bin ehrlich gesagt ziemlich verärgert, weil meine Argumente
entweder nicht gelesen werden oder zumindest offensichtlich nicht
verstanden wurden.

> > > Zunächst werden die Knoten wohl ohnehin nicht ganz "gleich", wir
> > > müssen
> > > ja immer noch die unterschiedlichen Config-Files includen.
> > 
> > Hm? Ne, innerhalb eines bsp ist es erstmal gleich.
> > 
> > > Im Prinzip aber bauen wir hier eine Sonderwurst, die aus dem
> > > Konzept
> > > von OpenWrt ausbricht.
> > 
> > Die OpenWRT Menschen konnten nicht benennen, warum man das so nicht
> > tun
> > sollte. Das ist also kein Problem.
> 
> Wo hast du das nachgefragt? Auf deren Mailingliste habe ich nix
> gefunden.

Im IRC.

> > > Das führt dazu, dass wir immer nachdenken
> > > müssen, ob wir das richtig machen und bei neuen Patches ggf.
> > > Anpassungen notwendig werden. Das wäre u.U. gerechtfertigt, wenn
> > > sich
> > > bei den Split-Targets relevante Nachteile ergeben würden. Die
> > > sehe ich
> > > aber im Moment nicht.
> > 
> > Die Nachteile eines neuen BSPs sind, dass wir zwei BSPs haben, die
> > auseinander laufen werden, obwohl das unnötig ist. Weiter werden
> > wit
> > ständig aufpassen müssen nicht aus versehen eines der subtargets
> > kaputt zu
> > machen.
> 
> Dies .config hat doch eigentlich nur eine untergeordnete Rolle.
> Solange die 
> Abhängigkeiten der Freifunk-Pakete richtig modelliert sind, sollte
> das doch 
> eigentlich wenig Auswirkungen haben. Falls unterschiedliche BSPs
> SOOOO schlimm 
> sind, sollten wir uns vielleicht auch überlegen den Mechanismus ganz
> los zu 
> werden. Wer nutzt denn schon einen power pc ;-) ?
> 
> Schön ist es sicher nicht zwei BSPs zu pflegen. Aber die Erklärung
> warum das 
> _so_ aufwändig sein soll, wie du tust, bleibst du uns meiner Meinung
> nach 
> schuldig.
Ich denke das habe ich hinreichend erklärt. Aber ich werde es gern noch
ein mal wiederholen:

Fakt 1:
- Die BSPs werden auseinander laufen und der Pflegeaufwand steigt (man
muss jeden Patch mehrfach bauen, und prüfen, ob es keine Quereffekte
durch das generic/tiny Target gibt)

Fakt 2:
- Die Namen ändern sich

Fakt 3:
- Die User werden nicht verstehen, warum einige Freifunk-Knoten anders
sind als andere

> > > Nutzen wir die Split-Targets, müssen wir nur ein einziges Mal die
> > > bsps
> > > aufteilen (= Copy/Paste) und dann die sysupgrade-Namen anpassen.
> > > Damit
> > 
> > Stimmt nicht. Dein Patchset ist doch das perfekte Beispiel, es
> > zeigt wie
> > sehr das beim upgrade path verwirrt. Das ist einfach ein riesen
> > Chaos, was
> > vermeidbar ist.
> 
> Bei Adrians Argument gehe ich mit, deins scheint aber etwas verkürzt.
> Was 
> zeigt sich da wo?
Lese dir meine Kommentare gern hier durch:
http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2018-August/014449.html

Erklärend: In dem Code wird ein riesen Abwasch gemacht, der nicht nötig
ist. Weiterführend sind die Dateinamen vermutlich zu lang.

> Die Namen haben sich (mal wieder) geändert. Was bedeutet das 
> für die Zukunft? Könntest du das erklären? Die Aufwandsabschätzung
> die Adrian 
> weiter unten liefert erschließt sich mir erstmal sehr gut.

Hier hat Adrian einen sehr hohen Aufwand abgeschätzt, einen OpenWRT
Patch zu designen:
http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2018-August/014479.html

Das ist ja wohl hinreichend mit
http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/2018-August/014490.html
widerlegt.

Wie man sehen kann, ist der eigentliche Patch ist trivial!

Da ist auch sofort ersichtlich, dass es keine größeren Folge-Aufwände
gibt. Somit wäre das Argument von Adrian auch widerlegt.

> > > ist die Sache erledigt und es fallen keine nachträglichen
> > > Wartungsschritte mehr an (Ich verwende den Spaß ja jetzt schon
> > > seit
> > 
> > In meinem Patch sind wir die Wartungsarbeiten los, ja. Bei deinem
> > geht die
> > Arbeit erst los.
> 
> Welche Wartungsarbeiten meinst du denn? Am Schluss sind wir immer von
> openwrt 
> abhängig. 
Ja, das ist richtig. Aber wie ich in meinem Patchset zeige ist die
Änderung seitens OpenWRT im Grunde nur das tiny Target. Eine Aufteilung
ist unnötig.

> Und gerade wegen den volatilen Namen(was ich bisher als deinen 
> Hauptgrund für die Verwirrung, die jetzt herrscht) haben wir ja eben
> schon 
> eine entsprechende Abstraktion gebaut.
Wir haben keine entsprechende Abstraktion! Wir auf dem Download-Server
ein Script, was statische Dinge im Namen der Datei ändern kann. Damit
kann es aber noch lange nicht unterscheiden, ob ein Gerät nun 4 MB hat
oder nicht.

> 
> > > über 4 Monaten), da wir ja einfach OpenWrt so benutzen, wie es
> > 
> > Es ist so nicht vorgesehen. Die OpenWRT Menschen wussten da doch
> > selber
> > nicht was sie tun. Ich hab doch extra nachgefragt.
> 
> Wieder die Frage wo?
Immer noch im IRC.

> 
> > > nur, wenn man wirklich Geräte aus beiden Subtargets braucht (und
> > > halt
> > > jeweils einmal pro halbem Jahr für ein Release).
> > > 
> > > Bevor Tim und ich jetzt aber noch drei Mal die gleichen Meinungen
> > > austauschen, ist das wohl ein Punkt, wo die Meinungen der anderen
> > > Entwickler hilfreich wären. Dafür sind die beiden alternativen
> > > Patchsets ja bestens geeignet.
> > 
> > Im Grunde ja. Aber am Ende brauchen wir einen Konsens. Ich hab mir
> > damals
> > deine Patches angeschaut und eklatante Mängel gefunden. Zum einen
> > an der
> > Architektur zum anderen an den Probleme die diese Architektur nach
> > sich
> > ziehen. Es würde also Probleme in der Nachhaltigen Entwicklung
> > bereiten.
> > Alles nicht schlimm, dafür machen wir ja den ganzen review kram.
> > Ich habe
> > dich im Rahmen eines Konsens gebeten ein paar Dinge anzupassen. Ist
> > aber
> > leider nicht passiert. Also habe ich selber den Konsens gebaut. Und
> > das
> > hier ist das Ergebnis. Es ist eigentlich keine Alternative sondern
> > die
> > Weiterentwicklung deines Pachtssets, weil du leider nicht mehr
> > weiter
> > machen wolltest.
> 
> Nur weil etwas deiner Meinung nach "eklatant" ist, kann man trotzdem
> drüber 
> diskutieren und muss nicht blind deine Anmerkungen umsetzten. Genau 
Es wurde diskutiert. Es wurden Argumente getauscht und es wurden
Agurmente ausgeräumt.

Am Ende zeigt sich, es gibt eigentlich kein Plus-Punkt für ein
separates BSP, sondern nur noch Nachteile. Hingehend gibt es keine
Nachteile, wenn man bei einem BSP bleibt. Die behaupteten Nachteile
wurden alle widerlegt. So lange da auch keine neuen Argumente kommen
ist das Thema für mich erledigt.

> das ist 
> hier passiert. Adrian hier jetzt eine Art Verweigerungshaltung
> vorzuwerfen, 
> trifft die Wahrheit meiner Meinung nach nicht.
Nochmal:
Die Argumente wurden ausgetauscht und entkräftet.

Ja, vielleicht hätte ich auch noch länger warten können, aber die
Erfahrung zeigt, dass bei wichtigen Architektur-Anmerkungen meinerseits
selten eine Nachbesserung erfolgt. Das ist eben auch der Grund, wieso
ich gleich ein eigenes Patchset geschrieben habe, weil mir schon klar
war, dass wir da einfach nicht weiter kommen. Tut mir leid, das ist
einfach meine persönliche Erfahrung mit der Situation.

Das Ergebnis ist, dass wir jetzt alle sauer sind. Prima.

So, jetzt habe ich extra alle wichtigen Punkte nochmal zusammen
gefasst. Ich habe wirklich keine Lust mich anschließend nochmals zu
wiederholen. Es macht einfach kein Spass, wenn man da viel Zeit
investiert (was sich andere ja erstmal sparen), dann eklatante Probleme
findet, diese diskutiert werden, aber dann keine Nachbesserung erfolgt.
 Dann kann ich mir das Review auch gleich sparen, wie alle anderen eben
auch! Ich bin es wirklich leid. Reviewed doch alleine! Danke.

Tim

> Viele Grüße
> Tobias
> 
> 
> > > Beste Grüße
> > > 
> > > Adrian
> > > 
> > > > -----Original Message-----
> > > > From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On
> > > > Behalf
> > > > Of Tim Niemeyer
> > > > Sent: Dienstag, 7. August 2018 07:09
> > > > To: franken-dev at freifunk.net
> > > > Subject: [Alternative PATCH 0/7] Alternatives Set zum OpenWrt
> > > > 18.06
> > > > 
> > > > 
> > > > Dieses Patchset basiert auf dem OpenWrt 18.06 v3 Patchset von
> > > > Adrian,
> > > > allerdings wird kein neues BSP eingeführt sondern tiny wird für
> > > 
> > > ar71xx als
> > > 
> > > > default genommen.
> > > > 
> > > > Wir können so die Gleichheit der Knoten besser unter Kontrolle
> > > 
> > > halten.
> > > 
> > > > Das erspart uns langfristig viel Arbeit, weil Dinge auf einer
> > > > Knoten
> > > 
> > > Art gehen
> > > 
> > > > und auf der anderen nicht.
> > > > 
> > > > So lange wir die 4 MB Geräte unterstützen wollen müssen wir uns
> > > > immer
> > > 
> > > um
> > > 
> > > > den Speicherplatz kümmern, da macht es quasi keinen
> > > > Unterschied, ob
> > > 
> > > wir
> > > 
> > > > _alle_ Geräte auf 4 MB begrenzen oder nur ein paar.
> > > > 
> > > > Mit dem Patch die Geräte alle auf tiny zu bauen, fahren wir
> > > 
> > > langfristig
> > > 
> > > > vermutlich auch keine Rückportierungsprobleme, weil es faktisch
> > > > keine
> > > 
> > > Rolle
> > > 
> > > > spielt, ob ein Target für generic oder tiny entwickelt wurde.
> > > > 
> > > > Wir sollten aber nochmal überlegen, ob es eventuell ungünstig
> > > > für die
> > > > Gateway Firmware wird. Desweiteren wäre zu überlegen, ob das
> > > > wdr4900
> > > > Target ggfs auch beschnitten werden sollte um das System weiter
> > > > anzugleichen.
> > > > 
> > > > Hinweis: Da scheint irgendwo ein parallel-build Fehler zu sein.
> > > > :(
> > > 
> > > Ich konnte
> > > 
> > > > im ersten Durchlauf nur mit einem Job sauber bauen, ansonsten
> > > > musste
> > > 
> > > ich
> > > 
> > > > immer zweimal bauen. Der MR3020 baut immer noch nicht.
> > > > 
> > > > Tim
> > > > 
> > > > Adrian Schmutzler (4):
> > > >   OpenWRT: Update OpenWrt, packages and routing to openwrt-
> > > > 18.06
> > > >   fff-boardname: Fix changed board name of WDR4900v1
> > > >   fff-firewall: Fix match in ip6tables and add dependencies
> > > >   root_file_system: Remove sysctl.conf
> > > > 
> > > > Tim Niemeyer (3):
> > > >   OpenWrt: Use the tiny target and update names
> > > >   fff-sysupgrade: Update sysupgrade.sh to support openwrt-18.06
> > > >   OpenWrt: Save space
> > > >  
> > > >  bsp/ar71xx/.config                                 | 139 ++--
> > > >  bsp/board_ar71xx.bsp                               |  68 +-
> > > >  bsp/board_wdr4900.bsp                              |   2 +-
> > > >  bsp/default/root_file_system/etc/sysctl.conf       |   1 -
> > > >  .../openwrt/0001-sysupgrade-no-config-save.patch   |  12 +-
> > > >  build_patches/openwrt/0002-set-root-password.patch |   6 +-
> > > >  .../openwrt/0003-ntpd-host-as-string.patch         |   6 +-
> > > >  ...tats.patch => 0004-ar71xx-4.9-l2tp-stats.patch} |  12 +-
> > > 
> > > .../0005-allow-
> > > 
> > > > building-all-devives-as-tiny.patch  |  28 +
> > > 
> > > ...ils-tplink-safeloader-support-
> > > 
> > > > strings-as-.patch | 164 -----
> > > 
> > > ...1xx-add-support-for-TP-Link-Archer-C25-
> > > 
> > > > v1.patch | 501 ---------------
> > > 
> > > ...ils-tplink-safeloader-add-TP-Link-Archer-.patch
> > > 
> > > > > 114 ----  ...mware-update-qca9887-firmware-to-10.2.4-1.patch
> > > > > |  41
> > > 
> > > --  ...ils-
> > > 
> > > > mktplinkfw-rework-combined-image-opti.patch | 264 --------
> > > 
> > > ...mktplinkfw-
> > > 
> > > > combined-command-to-image-comm.patch | 103 ---  ...13-ar71xx-
> > > > add-
> > > > support-for-TL-WR1043N-v5.0.patch | 697 ---------------------
> > > 
> > > ...do-not-apply-
> > > 
> > > > broken-power-limits-with-ATH.patch | 173 -----
> > > 
> > > ...-remove-bs-partition-ro-
> > > 
> > > > flag-for-UniFi-AC.patch |  36 --
> > > 
> > > ...ort-interface-IDs-with-more-than-two-
> > > 
> > > > digi.patch |  35 --
> > > > 
> > > >  buildscript                                        |  12 +-
> > > >  .../files/etc/uci-defaults/50-fff-boardname        |   3 +
> > > >  src/packages/fff/fff-firewall/Makefile             |   5 +-
> > > >  .../files/usr/lib/firewall.d/20-filter-ssh         |   4 +-
> > > >  .../fff/fff-sysupgrade/files/etc/sysupgrade.sh     |  14 +-
> > > >  24 files changed, 172 insertions(+), 2268 deletions(-)  delete 
> > > > mode
> > > 
> > > 100644
> > > 
> > > > bsp/default/root_file_system/etc/sysctl.conf
> > > > 
> > > >  rename build_patches/openwrt/{0004-ar71xx-4.4-l2tp-stats.patch 
> > > > =>
> > > 
> > > 0004-
> > > 
> > > > ar71xx-4.9-l2tp-stats.patch} (83%)  create mode 100644
> > > > build_patches/openwrt/0005-allow-building-all-devives-as-
> > > > tiny.patch
> > > > 
> > > >  delete mode 100644 build_patches/openwrt/0005-firmware-utils-
> > > > tplink-
> > > > 
> > > > safeloader-support-strings-as-.patch
> > > > 
> > > >  delete mode 100644
> > > 
> > > build_patches/openwrt/0006-ar71xx-add-support-for-
> > > 
> > > > TP-Link-Archer-C25-v1.patch
> > > > 
> > > >  delete mode 100644 build_patches/openwrt/0007-firmware-utils-
> > > > tplink-
> > > > 
> > > > safeloader-add-TP-Link-Archer-.patch
> > > > 
> > > >  delete mode 100644
> > > 
> > > build_patches/openwrt/0008-ath10k-firmware-update-
> > > 
> > > > qca9887-firmware-to-10.2.4-1.patch
> > > > 
> > > >  delete mode 100644 build_patches/openwrt/0011-firmware-utils-
> > > > 
> > > > mktplinkfw-rework-combined-image-opti.patch
> > > > 
> > > >  delete mode 100644 build_patches/openwrt/0012-build-move-
> > > > mktplinkfw-
> > > > 
> > > > combined-command-to-image-comm.patch
> > > > 
> > > >  delete mode 100644
> > > 
> > > build_patches/openwrt/0013-ar71xx-add-support-for-
> > > 
> > > > TL-WR1043N-v5.0.patch
> > > > 
> > > >  delete mode 100644
> > > 
> > > build_patches/openwrt/0020-Revert-ath-do-not-apply-
> > > 
> > > > broken-power-limits-with-ATH.patch
> > > > 
> > > >  delete mode 100644 build_patches/openwrt/0031-ar71xx-remove-
> > > > bs-
> > > > 
> > > > partition-ro-flag-for-UniFi-AC.patch
> > > > 
> > > >  delete mode 100644
> > > 
> > > build_patches/routing/0001-alfred-Support-interface-
> > > 
> > > > IDs-with-more-than-two-digi.patch
> > > > 
> > > > --
> > > > 2.11.0
> 
> 
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 488 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20180814/73171c7c/attachment.sig>