Web-UI in eigenes Repository (war: [PATCH v4 1/1] Add Leaflet-Map Position selector)

[Florian Schimmer]

Hi Leute,

ich geb auch mal meine Meinung dazu ab:

Hier werden gefühlt gerade ein paar Dinge vermischt.

Ist immer gut, GUIs austauschbar zu machen. Hat aber erst mal mit dem 
Repository nix zu tun. Die separat testbar und ausführbar zu machen geht 
auch im selben Repository.

Dann sprecht ihr noch über Feature-Branches. Bin ich auch ein riesen 
Freund davon und sollten (und werden wir, so wies aussieht) auch drüber 
reden. Aber es sollte nicht der ausschlaggebende Punkt sein, ein neues 
Repository aufzumachen, um den eigenen Workflow umzusetzen. Alternativ 
kann man auch in einem Repository für Subsysteme einen eigenen Workflow 
definieren. Finde ich zum ausprobieren auch nicht so verkehrt.

Sinn macht so eine Trennung meiner Meinung nach nur, wenn wir das 
Web-Interface entweder noch woanders einsetzten oder mehrere 
Web-Interfaces unterstützen möchten.

Wenn ihr eins davon jetzt schon mit ja beantworten könnt, dann bin ich 
auch dafür, ein neues repo aufzusetzen. Wenn nicht, bin ich dafür, die 
GUI ordentlich innerhalb des repos zu trennen und erst wenn einer der 
beiden Punkte zutrifft, das Zeug raus zu ziehen.

Liebe Grüße,
Flo


Am 26.01.2016 21:24 schrieb delphiN:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am 26.01.2016 20:09, schrieb Tobias Klaus:
>> Ich denke am einfachsten wäre es hier einfach mal zu skizzieren was
>> du so vor hast. Jeder der an der Entwicklung beteiligt ist kann
>> sich dann damit abstimmen oder Anmerkungen machen. Damit könnte man
>> doppelte Arbeit sparen und schon im Vorfeld einen entsprechenden
>> Austausch mit den Aktiven pflegen.
> 
> Als erstes würde ich ganz gerne mal bestehende JavaScript Warnungen
> und Fehler fixen und die ganze Oberfläche auf das Pure-UI-Framework
> umstellen um dieses 90er-Jahre-Flair loszuwerden. Damit hat ja Dominik
> schon angefangen. Hier kann man sicherlich zusammenarbeiten.
> 
>> Das aktuelle Web-UI ist integraler Bestandteil der aktuell ziemlich
>>  tiefgreifenden Weiterentwicklung der Firmware selbst,
>> beispielsweise was den dezentralen Umgang mit Hoods und Knotendaten
>> angeht. Ich denke nicht, dass es Sinn macht das hier zu trennen.
> 
> Ein UI sollte möglichst nie direkt mit den Internas verknüpft sein.
> Falls es hier eine starre Bindung gibt sollte diese meiner Meinung
> nach durch eine API aufgelöst werden.
> 
> Eine derartige Integration in das System kann ich allerdings gar nicht
> erkennen. Es geht mir eigentlich nur um das package "fff-web". Dort
> werden eigenständige cgi-skripte aufgerufen die man auch beliebig
> austauschen könnte. Ganz zu schweigen vom html, css und Javascript.
> 
> Damit eine UI für Franken verwendet werden kann muss es halt die
> nötigen nodewatcher-Daten bereitstellen. Letztendlich entscheidet Ihr
> welches Web-Interface in eure Firmware kommt. Ich seh da ehrlich
> gesagt nicht das Problem.
> 
>> Wie schon gesagt, macht eine solche Trennung eigentlich keinen
>> Sinn, einerseits brauchen wir meines Erachtens nicht noch einen
>> Kanal und nicht noch ein Repository, andererseits sind die
>> "Internals" eben doch recht eng verknüpft.
> 
> Die Firmware ist schon heute von min. 3 weiteren Repositories
> abhängig. Auch hier werden ja nicht einfach die Sourcen kopiert
> sondern extern gezogen. Aus meiner Sicht macht eine Aufteilung in
> Module fast immer "Sinn".
> 
>> Auch wenn es mal andere Oberflächen geben wird(siehe Kommentar
>> unten) wird die aktuelle Weboberfläche erstmal sowas wie eine
>> Referenzimplementierung sein.
> 
> Als Referenzimplementierung ist sie auch sehr brauchbar. Will man sie
> aber durch Alternativen wie z.B. luci2 oder z.B. eine reine API für
> eine native Knoten-Managemant-App ersetzen muss man erst die
> bestehenden Webseite aus der firmware "herauskratzen". Das geht jetzt
> noch deutlich einfacher als in ein paar Monaten!
> 
>> Weshalb Feature-Requests und Bugreports für die Weboberfläche
>> getrennt von denen für die Firmware verwaltet werden sollten
>> erschließt sich mir auch nicht so recht.
> 
> So eine Web-Interface ist keine funktional wichtige Komponente. Hier
> kann man auch mal schnell ein paar kleine CSS-Verbesserungen machen
> ohne, das gleich ein paar Spitzen-Ingenieure darüber schauen müssen,
> damit nichts "explodiert". Die Entwicklung könnte hier wesentlich
> schneller und unkomplizierter werden und auch Menschen zumindest
> einbinden, die sich nicht so tief in OpenWrt einarbeiten wollen. Das
> wäre eine tolle Möglichkeit die Entwicklung wieder etwas zu öffnen und
> mehr Mitarbeit nach den eigenen Möglichkeiten zuzulassen. Ich halte
> das für dringend notwendig.
> 
>> Auch hier wäre natürlich ganz interessant, mehr über deine Pläne zu
>> erfahren.
> 
> Ich habe mir Anfang diesen Jahres Zeit genommen mich in neue
> Technologien und Web-Frameworks einzuarbeiten. Hier würde ich evtl.
> eine zweite "Referenzimplementierung" mit eher experimentelle Features
> machen, wenn ich die Zeit und Muse finde. Hier schweben mir z.B.
> Live-Graphen, Last-Diagramme, Drag-And-Drop Interface-Management usw.
> vor. Ähnliche Features wie es z.B. die Ubiquity-Firmware oder eine
> Fritzbox heute mitbringen.
> 
> Auch habe ich bereits mit luci2 auf einem normalen OpenWrt einige
> Erfahrung gesammelt und würde das auch gern bei uns zum laufen bringen.
> 
> 
> Letztendlich kann ich ja jederzeit das Repository forken und meine
> Änderungen vornehmen. Genau das habe ich ja auch schon getan.
> Aber es ist glaube ich weder für mich noch für "euch" wünschenswert,
> wenn wir an einander vorbei arbeiten.
> Mein Plan ist eigentlich jede größere Änderung in einem eigenen
> Feature-Branch zu machen und euch diesen als Pull-Request bei
> Github/Gitlab bereit zu stellen. So arbeite ich und alle Firmen bei
> denen ich bisher war Tagein Tagaus und ich sehe absolut keinen Grund
> mich hier (wegen Einzelpersonen) zu verbiegen. Wenn Ihr
> Fehlerbehebungen oder neue Features haben wollt ist es eure Aufgabe
> euch die zu holen und nicht meine die den Hohenpristern auf dem
> Silbertablet vorgekaut vorzusetzen!
> Mit so einer Einstellung kommen wir uns aber wohl nie näher, deshalb
> wäre ich für einen Kompromiss bereit:
> 
> Wenn Ihr das bestehende Web-Interface ausgliedert wäre ich bereit alle
> Verbesserungen daran als saubere Patches über die Liste einzureichen
> und Änderungswünsche auch über die Mailingliste entgegenzunehmen (auch
> wenn sich mir dabei die Fusnägel aufrollen). Die Kontrolle an dem
> neuen Repository "fff-web" könnte voll beim bestehenden
> "firmware-development" Team bleiben. Ich will euch nichts wegnehmen
> sondern einfach Mitarbeiten ohne mich zu verbiegen!
> 
> Diese Ausgliederung würde es mir deutlich vereinfachen parallel mit
> weiteren Implementierung zu experimentieren ohne auf die wichtigen
> Änderungen an der Firmware verzichten zu müssen.
> 
> Könntet Ihr damit Leben? Wie sehen das die Anderen?
> 
> delphiN
> 
> - --
> Freifunk-Franken, Förderverein Freie Netzwerke e.V.
> eMail: freifunk at wunschik.net
> XMPP : delphiN at jabber.ccc.de
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> 
> iQIcBAEBAgAGBQJWp9YYAAoJEGuH2dOBPapClbMP/0IgFB+lb6gEVhLNY2xBz3tF
> mwlvScoK+MrcOP90rHg0juKgo+iuRF41zB92evusCP6vlvP6ZYn2g5dyMueUWm8O
> k4XXPFAKXSwEKLoVGHF3knVv9ZmN9yFJVd++IMmCZwdU5PO1Lbz9yCXUQp8JY5XP
> 8QvPG0CBtfruNQYUI5lr3gp8R/+UxsdzdSP/0vSzMLcDu4i5bnekcEYxknJNJ5za
> 2CSTddE+4J9OxmAa+XfxtFHZ+HcTH5QiWh5852VMrTodnAiXM46GmDSLghOFX/bU
> 5nMR1GNg+7uNzRyA76e1eHGo2s7tUahf3YDtkp49bqFD+4tVtbvSUV/A0R/Kg6KL
> 9tE3kYagpiqT1LE2HarfAoyjd7rsVhq8P4QFk6j6KJlf4in8FwTiFP/TWYxlijDN
> KdndxVO0a/crM7kEqbCGJ0roDs3R5iDue4sRkrSXjs/DI+9gSLswBV7VP4DXg0/Z
> jpsVny+UBsy98gfDAMnXOB2SmW6fnPT050eb1IQNQQD36NS/Ozw9s6CO8Rf8BfAa
> mGS1tNTxsmPEd5rhmke5xTYWxrr+zOyCSjBBQw8BdME1T81HSzR2h2RAMDdptX34
> dNWCUNnFNw4EVrvW8LvaDaFKsGYZ87l993YLlERHSC+z4eCo8aKfJ0pCt0Iz3KGj
> BJQJZQC69we9nywEi9FE
> =EnX8
> -----END PGP SIGNATURE-----