- √ - 1426: Icons weg?

[peuter]

Also alles was den Anwender dabei unterstützt weiterhin fehlerhafte Icon-Namen zu benutzen, ist hier aus meiner Sicht der falsche Ansatz. Egal ob Symlinks oder Verweise im iconhandler oder was auch immer. Damit schleppt man die fehlerhafte Benutzung immer weiter, später dann sogar mit ins nächste Release. Das sollte absolut vermieden werden.

Dann lieber einen klaren Schnitt, wie jetzt geschehen. Wer eine Entwicklerversion benutzt muss an der Stelle ein wenig schmerzfrei sein. Das das nervig ist kann ich nachvollziehen, ist aber nunmal so.

Wenn sich hier jemand die Mühe machen sollte ein mapping zu erstellen, dann ist IMHO der einzige Weg, daraus ein Script zu basteln, das alle Icons in einer Config passend ersetzt. Damit schafft dann jeder der es noch nicht von Hand gemacht hat auch einen schnellen Umstieg.

[ctr]

Eure Meinung in allen Ehren, aber ich sehe das anders.

1. Bin ich kein "End-Anwender" sondern selbst Entwickler. Nur weil ich in letzter Zeit nicht so viel eingecheckt habe beschäftige ich mich trotzdem aktiv mit der Materie und dazu gehört IMHO auch die aktive (!) Benutzung der SVN Version. Wenn ich das nicht tun würde, hätte ich bei dem derzeitigen Stand der Doku keine Ahnung mehr, was die CV denn zur Zeit überhaupt kann. (Und das obwohl ich als Moderator hier wirklich *jeden* Thread zumindestens eingangs lese.)
2. Sehe ich nicht, dass es dafür "viel zu früh" ist, hier wurden schon Endanwender zum Testen aufgerufen.
3. Wurde an mehreren Stellen bereits aufgerufen Beispielconfigs zur Verfügung zu stellen, was ich als meinen Beitrag dazu (mangels js Know-how) auch aktuell tun wollte.
4. Entspricht es nicht gängigen Commit-Praktiken etwas kaputtzumachen ohne dies entsprechend anzukündigen. Der Commit Kommentar lautet

bug 3603283: adapted structure for knx-uf-iconset in icon database
additionally cleaned up the knx-uf-iconset by just using the latest versions with English names

Das ist für mich kein "Clean-Up" wenn etwas Config-Änderungen verursacht, Entwickler-Version hin- oder her. Wenn soetwas im Linux-Kernel passieren würde (und auch dort handelt es sich zunächst um Entwicklerversionen bevor es zum nächsten Release kommt) würde sich der Maintainer aber mächtig aufregen.
Das soll jetzt keine Kritik am Comitter sein: der Bug sollte gefixed werden und die Namen an die neuen Namen von mfd anzupassen macht auch Sinn. Aber im Gegensatz zu peuter sehe ich durchaus, dass man für einen Übergangszeitraum eine Lösung anbieten sollte. In der Doku (und auch showcons.php) stehen nachher die richtigen Namen, d.h. wenn jemand neu anfängt dann wird er auch die Richtigen benutzen.

[Chris M.]

2. Sehe ich nicht, dass es dafür "viel zu früh" ist, hier wurden schon Endanwender zum Testen aufgerufen.

Nicht ganz, es waren nur Anwender und die auch nur hier im Entwicklungsforum, denn auf der Start-Seite heißt es ja schon extra: "Deutschsprachiges CometVisu Entwicklerforum"
Außerdem ist Testen für mich noch etwas anderes als (produktiv) Nutzen - dafür sind wir noch zu früh!

Von den Kleinlichkeiten mal weg:
Ich verstehe natürlich, dass es extrem ärgerlich ist, wenn durch eine externe Umstellung die eigene Arbeit zurück geworfen wird. Und das auch noch für etwas was wir alle freiwillig und in unserer Freizeit machen - die Mehrarbeit hätte man wirklich in etwas sinnvolleres investieren können.

Aber dennoch ist der Schritt der Icon-Umbennung zum jetzigen Zeitpunkt richtig - denn jeder andere Zeitpunkt wäre nur später gewesen und folglich noch schmerzhafter!

Manchmal muss man leider in den sauren Apfel beißen und solche Unannehmlichkeiten hinnehmen, um sich später noch deutlich unangenehmere zu ersparen. Das Mitziehen von Leichen zähle ich da explizit dazu.
Wenn man nun dem Anwender in seiner produktiven Seite etwas kaputt macht, dann halte ich es für notwendig für Abhilfe zu sorgen (z.B. mit einem Update-Skript).
Bei einem Entwickler ist's eine Frage der Nutzen und Aufwandsberechnung. Hier ist aber auch Selbsthilfe möglich (im Gegensatz zu den meisten Anwendern) - ein Entwickler könnte sich schnell mal ein Übersetzungsskript schreiben und anderen zur Verfügung stellen. Vermutlich waren die meisten notwendigen Änderungen aber so klein, dass hier niemand den Aufwand dafür als sinnvoll angesehen hat.

Da sicher auch in der Zukunft inkompatible Änderungen kommen werden, hier noch mal die allgemeine Richtlinie zum SVN Commit:

Nach einem Commit sollte die CometVisu immer funktionieren. Maßgeblich ist die Demo-Config.

So wie die dazu ergänzende Regel:

Wenn man das nicht einhalten kann, sollte man das vorher klären.

Ob das "funktionieren" hier eingehalten wurde oder nicht könnte man diskutieren - aber da diese Änderung vorher abgestimmt war, ist für mich diese Änderung korrekt abgelaufen.

[swiss]

Ja. Das alles in Ehren... ABER...

Klar muss man Leichen beseitigen so früh wie möglich. Allerdings sollte man dann irgend wann einen Punkt setzen wo die Struktur der Konfig so wie das Verhalten und aussehen der Visu Stabil ist. Dazu ist ja der Featurefreez vor dem internen BETA Test. Denn wenn bis zur Releas immer wieder grobe Änderungen gemacht werden, dann kannste weder einen vernünftigen BETA Test durchführen noch eine vernünftige Doku dazu erstellen...

Ich habe mir das Thema Doku aufarbeiten noch nicht angetan, da ich noch keine "Garantie" z.B. in Form eines Featurefreez erhalten habe. Solange die Struktur nicht stabil ist, macht es in meinen Augen keinen Sinn da zuviel Zeit rein zu stecken.

Allerdings ist das natürlich wieder doof da ein Rattenschwanz...

Die Doku braucht Zeit (Ausser es melden sich viele freiwillige Helfer). Wenn du also ein baldiges Releas planst, solltest du unbedingt sehr bald für Stabilität in allen Dingen sorgen, die den Nutzer unmittelbar betreffen...

Sprich:

- Aussehen und Funktionen der Widgets
- Aussehen und Funktion des Editors
- Aufbau und Syntax in der config.xml

Davon ausgenommen sind natürlich Bugfix aber die haben auch nur selten Einfluss auf die Syntax oder das Aussehen der Visu bzw. des Editors...

Bedenke, dass selbst wenn ich einen grossteil meiner Freizeit in die Doku stecke, ich alleine für die Aufarbeitung ca. 2 Monate brauche (kämpfe da etwas auf verlorenem Posten..)

Darum sollten wir nochmal darüber sprechen, wann der BETA Test starten soll und an dem Tag auch einen Freez verhängen. Sonnst wird das in meinen Augen nix

[Chris M.]

Da hast Du natürlich recht. Der grobe Ablauf ist auch unter https://knx-user-forum.de/cometvisu/...bereitung.html im Eingangsposting beschrieben.

Genauere Planungen sollten im o.g. Thread besprochen werden, daher hier nur ganz grobes:
Wir sind aktuell in einer Phase mit vielen, schnellen Änderungen. Die dienen v.a. bestehende Defizite (ob Bug oder Feature Request ist da egal) zu beseitigen. Und gerade da ist es wichtig die Freiheit zu haben, notfalls auch etwas inkompatibles zu machen und z.B. aufzuräumen. Aber genau so wichtig ist, dass viele den Code testen. Testen und Debuggen gehen Hand in Hand.

Wenn sich das nun etwas stabilisiert, dann würde ich den Freeze der internen Strukturen anstreben.
Ab hier macht es Sinn bei der Doku u.ä. von Vorbereitungen zur realen Umsetzung zu gehen.
Genau so werde ich ab dann mit den Preview-Releases anfangen (schließlich muss der Prozess auch noch entwickelt werden - und der braucht halbwegs stabile Strukturen...)
(Für Deine Planung: ich rechne mit wenigen Wochen; wer's genauer will, muss sich nur einen Überblick über die für 0.8.0 offenen Bugs besorgen)

Hier kann dann noch der Editor reifen (z.B. im Design, nicht in der grundsätzlichen Metapher), die Doku perfektioniert werden und der Code final seine Bugs ablegen.
Hier kann sich auch die Test-Tiefe deutlich erhöhen, weil auch alle ohne SVN die CometVisu ausprobieren können.

Und dann wären wir schon bei der 0.8.0 angekommen

[swiss]

Gut Dass hört sich nach einem Plan an Ich habe mir für die neue Doku einiges vorgenommen. Nicht nur die CometVisu soll Fortschritte machen...

Sobald also das OK&GO von eurer Seite kommt, also die Visu "Stabil" ist, werde ich versuchen so schnell wie möglich die gesammte Doku zu überarbeiten.

[Chris M.]

Klingt auch gut!

Und wie geschrieben - mit Vorbereitungen kannst Du schon anfangen. Da wo's einen konkreten Bezug bekommt kann's aber noch bisschen warten.

[swiss]

Ok. Dan schaue ich, dass ich mal mit der "Infrastruktur" beginne. Also Navigation, Seiten-Layout usw... Mehr zur Planung wie von dir vorgeschlagen im "Release Vorbereitung" Thema