[PATCH v3 3/3] gateway.d: Add scripts for network configuration

Tim Niemeyer tim at tn-x.org
Mi Mai 8 22:17:28 CEST 2019


Am Mittwoch, den 24.04.2019, 18:39 +0200 schrieb Adrian Schmutzler:
> Hallo Fabian,
>  
> ich beschränke das jetzt mal auf den technischen Teil:
>  
> > Wichtig ist halt immer, dass die Architektur passt, wie andere es
> auf dieser Mailingliste schon häufiger mal eingebracht haben.
>  
> Genau, mir geht es um die Architektur. Ich will nicht jetzt nochmal
> auf etwas aufbauen, was ich (und scheinbar auch andere) unpraktisch
> finde(n) und loswerden will/wollen.
>  
> > Aber wenn es einfach ist, dann könntest du das ja auch noch mit in
> dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und
> nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung
> eigentlich nichts zu tun hat.
>  
> Mein Patchset ist fertig und komplett reviewed. Dein Patch 3/3 ist 
Ich habe großen Respekt vor dem Reviewer und natürlich auch vor deiner
Arbeit.. Ich habe mich gerade gefragt, warum ich keine Ahnung habe, um
was es in deinem Patchset geht. Ich habe die letzten Wochen immer nur
sporadisch in die Liste reingeschaut. Meistens ging es um irgendwelche
"Node" Sachen, die mich weniger interessiert haben. Da ich wenig Zeit
habe, habe ich diese daher liegen gelassen. Ich habe von keinem Konzept
gehört, welches das configurenetwork ordentlich umbaut. Das wundert
mich, weil das configurenetwork kommt von mir und da wäre es nur fair
einbezogen zu werden. Aber sei es drum. Ich habe gerade versucht das
Patchset anzuschauen, aber.. Das ist ja sowas von durchwachsen. Tut mir
leid, 
a) dass ist zu groß
b) ich finde kein Einstiegspunkt
c) die Patchversionen sind alle durchgewürfelt und es gibt keine
sauberen Threads. Mal ist der Coverletter in 0/x (wo er hin gehört)
manchmal in 3/x .. Wie soll ich das mit meiner wenigen Zeit denn
schaffen da den Überblick zu behalten?

Ja, das configure-network ist ein gewachsenes Konstrukt. Am Anfang war
die Architektur davon noch ok, weil es einfach war und wenig gemacht
hat. Mitunter kamen immer mehr Sachen dazu und wir haben jetzt ein
Biest. So etwas kann einer alleine nicht mal eben über Nacht umbauen.
Selbst wenn einer allein ein Patchset schreiben kann, dann hängt er
damit einen Großteil der anderen Entwickler einfach mal ebenso ganz
direkt ab. Solche großen Änderungen müssen besprochen werden und müssen
mitwachsen. So etwas dauert bei unseren Ressourcen kurz gesagt ewig.

Letztlich höre ich bei dir, Adrian, viel Frust raus. Vermutlich hast du
viel Zeit in das Patchset gesteckt, und ich freue mich auch total, dass
du dir die Arbeit gemacht hast. Leider braust du mit dieser Motivation
aktuell volle kanne gegen unser ewiges Ressourcen Problem. Du musst uns
einfach viel mehr Zeit geben deine Arbeit zu verstehen. Es geht beim
gemeinsamen entwickeln leider nicht nur darum ein Patchset zu bauen,
sondern man muss die anderen Entwickler auch abholen und mitnehmen. Bei
mir hast du das nicht geschafft und bei Fabian offenbar auch nicht. Das
führt jetzt zu einem Konflikt. Nun hast du inzwischen scheinbar leider
so viel Frust aufgebaut, dass du wohl die Segel gestrichen hast.
Schade, aber kann ich auch irgendwie verstehen. Ich wollte eine Zeit
lang auch einfach nur weg rennen. Sicherlich wäre es gut gewesen, wenn
die Entwickler und die interessierten sich mal am Tisch zusammen
gehockt hätten. Da hättest du z.B. die Gelegenheit gehabt deine
Vorstellungen für den Umbau von configure-network mal vorzustellen (am
besten bevor der Patch fertig ist), und so die anderen Leute abzuholen.

Hingegen bei der Gateway-Firmware, reden wir alle seit Jahren von
nichts anderem mehr. Da tauchen viele verschiedene Ideen auf, die
reifen und die werden besprochen (oft (leider) auch Abseits der
Mailingliste). Daher, auch wenn es mir um deine Arbeit in dem Patchset
leid tut, hat das für mich eindeutig Vorrang.

Auch bezüglich der Priorität liegt die Gateway-Firmware im Moment
vorne: Wir brauchen die an vielen Standorten, haben aber nichts. Das
configure-network ist hässlich, aber funktioniert.
 

> nicht reviewed und funktioniert nicht, da er einen CPUPORT braucht,
> den es nicht gibt.
Das ist ein ernstzunehmendes Problem.. Hmm..

Tim

> Du möchtest jetzt aber, dass mein fertiges Patchset darauf warten
> muss, dass dein Patch 3/3 repariert und reviewed wird. Danach soll
> mein fertiges Patchset durch einen zu reviewenden Patch ergänzt
> werden, der deinen Patch dann wieder ändert. Und bis das fertig ist,
> gibt es dann bestimmt schon den nächsten Patch, der so wichtig ist,
> dass er monatelang rumliegt und alle anderen Projekte blockiert.
>  
> Umgekehrt kann mein Patchset jetzt sofort applied werden, und ich
> habe bereits eine v4 deines 3/3 geschickt, die funktioniert und
> einfach reviewed werden könnte.
>  
> Am Ende muss bei einem Projekt, bei dem es unterschiedliche
> Komponenten gibt, halt immer irgendjemand umbauen. Und ich finde es
> nicht unfair, wenn da der gewinnt, der schneller fertig ist. Zudem es
> wie zuvor beschrieben hier auch noch einfacher ist, deinen Patch zu
> ändern. Und wenn dir der Umbau des einen Patches schon so
> schwerfällt, dann überlege mal, wie es meine Entwicklungsarbeit
> aufhält, wenn ich jetzt ewig auf die vierzehn Patches warten muss.
>  
> Eigentlich möchte ich das fertige Patchset und deine 1/3 und 2/3
> heute in den master einwerfen. Liegt alles schon fertig in meinem
> Repo.
>  
> Grüße
>  
> Adrian
>  
>  
> From: Fabian Bläse [mailto:fabian at blaese.de> Sent: Mittwoch, 24. April 2019 18:00
> To: Adrian Schmutzler <mail at adrianschmutzler.de>; franken-dev at freifun
> k.net
> Subject: Re: [PATCH v3 3/3] gateway.d: Add scripts for network
> configuration
>  
> Hallo Adrian,
> On 24.04.19 13:10, Adrian Schmutzler wrote: 
> > mein Patchset schafft die komplette configurenetwork und die
> network.* Files ab, worüber ich ausgesprochen glücklich bin und was
> ich für einen großen Fortschritt halte.
> Ob ich das gut finde oder nicht kann ich jetzt grade nicht
> beantworten, da müsste ich erstmal deine Patches angucken. Sind ja
> immer 14! Stück.
> > Das mit dem vorwärts kommen ist halt so eine Sache: 
>> > Dieser Patch hier lag zuletzt einen Monat rum, bevor die v3 kam.
> Das ist kein Vorwurf, aber die Gatewayfirmware als Ganzes ist ja
> unbestreitbar ein langfristiges Projekt.
>> > Ich finde es daher nicht zielführend, jetzt für einen
> undefinierten, längeren Zeitraum jegliche Umbauten quasi zu
> verbieten, nur damit für das Einbauen der Gatewayfirmware weniger
> Aufwand betrieben werden muss. Weiterhin ist es ja so, dass die
> Umstellung für fff-network fertig ist, man also in jedem Fall den
> Gatewayfirmware-Patch dann direkt nach dem Merge des fff-network
> nochmal umbauen müsste. Das würde ich es schon lieber „gleich
> richtig“ machen.
> Stimmt, das ist ärgerlich. Bin leider nicht früher dazu gekommen :-(
> > (Ich könnte ja jetzt auch beleidigt sein und zum Thema „eines nach
> dem anderen“ darauf hinweisen, dass man mir nach dem letzten Release
> den configurenetwork-Patch in Aussicht gestellt hat, auf den ich
> insgesamt über ein Jahr warte.)
> Könntest du, hättest damit aber dennoch irgendwie unrecht, denn
> dieses Patchset hat mit deinem letzten so gut wie nichts mehr zu
> tun...
> > Gerade beim Einführen der Gatewayfirmware in das offizielle Repo
> erhoffe ich mir zudem, dass man dabei gerade versucht, das Ganze dann
> auch langfristig durchdacht zu machen (zum Beispiel sowas wie das
> gateway.d …), und nicht einfach alles reinwirft, damit es erst mal da
> ist. Sonst kann ja auch jeder weiter lokal vor sich hinpfriemeln.
> Klar kann man auch mal einen Kompromiss machen, aber jetzt da ein
> überholtes System neu einzubauen, nur um schneller fertig zu sein,
> wissend, dass man es dann gleich wieder umbauen muss, finde ich nicht
> zielführend.
> Jo. Aber wenn wir uns an jedem Patch an Kleinigkeiten so lange
> aufhalten, bis es absolut perfekt ist, dann sitzen wir irgendwann mit
> einer v27 da, bei der dann keiner mehr überblickt, was eigentlich
> geändert wurde.
> Wir sind noch relativ am Anfang des Entwicklungsprozesses
> "Gatewayfirmware", das wird schon noch etwas dauern, bis das fertig
> ist. Und bis dahin wird sich sowieso noch einiges hin und her
> schieben.
> Wichtig ist halt immer, dass die Architektur passt, wie andere es auf
> dieser Mailingliste schon häufiger mal eingebracht haben.
> > Zuletzt sei noch angemerkt, dass es ja auch gar nicht so schwierig
> ist, den einen betroffenen Patch hier jetzt gleich umzubauen, sodass
> er zum neuen System passt. Es geht im Prinzip nur um den einen Patch,
> dazu kommt dann vll. noch eine Zeile bei den babel-Sachen und ggf.
> beim Hoodfile, aber das ist alles überschaubar. Auch dein VLAN-Setup
> aus der /etc/config/gateway, was ja so oder so größtenteils redundant
> zur initialen Konfiguration ist, wird genauso funktionieren.
> Das kann ich halt wie gesagt aktuell nicht bewerten, ich hab das
> Patchset mangels Zeit noch nicht angesehen. 
> Aber wenn es einfach ist, dann könntest du das ja auch noch mit in
> dein Patchset aufnehmen. Dann hat man die Änderungen zusammen und
> nicht in irgendeiner v27 bei einem Patch, der mit dieser Änderung
> eigentlich nichts zu tun hat.
> > Ich werde auch gerne den Fortschritt der Gatewayfirmware
> beschleunigen und den Patch entsprechend überarbeiten, dass er zum
> neuen System passt. Die Patches 1/3 und 2/3 sind ja soweit fertig.
> Danke.
> Insgesamt sollten wir da jetzt vielleicht auch nicht allzu viel Zeit
> darauf verwerten zu Diskutieren, was jetzt zuerst kommt.
> Die Abhängigkeit zu fff-network ist eh nur klein und sollte in
> Zukunft sowieso weg. 
> Eigentlich sind das ja wie ich schon in der Commit Message
> geschrieben habe nur die Geräteeigenschaften.
> Gruß 
> Fabian
>  
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: This is a digitally signed message part
URL         : <https://{'listname': 'franken-dev-freifunk.net', 'hostname': 'lists.freifunk.net'}/pipermail/franken-dev-freifunk.net/attachments/20190508/eab1fba7/attachment.sig>


Mehr Informationen über die Mailingliste franken-dev