Entwickler Unterstützung gesucht - Release-Vorbereitung

[Chris M.]

Da der Editor nun einen wichtigen Meilenstein erreicht hat, wird es Zeit langsam Richtung des nächsten Releases zu schaun. Hier brauchen wir Euere Hilfe!

Im Grunde gibt es nun ein paar Phasen:

1. Feature Freeze
2. Freeze der internen Strukturen
3. Harter Freeze direkt vor dem Release

Auf einen (weichen) Feature Freeze(*) können wir uns wohl einigen, die aktuelle Version hat ja schon sehr viele Neuigkeiten, wie das ChangeLog weiß: SourceForge.net Repository - [openautomation] Contents of /CometVisu/trunk/ChangeLog

Somit würden wir als nächstes Richtung Freeze der internen Strukturen schauen - und genau da sehe ich noch Handlungsbedarf!
[HILFE]Ich such Unterstützung beim Aufräumen und polieren (neudeutsch: Refactoring) der internen Strukturen![/HILFE]
So ist z.B. die templateenginge.js inzwischen sehr "gewachsen".
Mit der der hatte ich damals angefangen, als ich noch nicht sonderlich viel über JavaScript Internas wusste... (Der iconhandler.js ist da schon deutlich weiter - und JavaScript Profis wissen sicher nochmals deutlich mehr)
=> Wer sich um was kümmern möchte, am besten vorher hier im Thread abstimmen.

Wenn das durch ist, würde ich die internen Strukturen freezen und mit Test-Builds anfangen. Das wäre auch der Zeitpunkt, wo möglichst alle offenen Bugs (vgl. SourceForge.net: Open Automation: Bugs) geschlossen werden sollten.
Ggf. sind auch noch ein paar Feature Requests (vgl. SourceForge.net: Open Automation: Feature Requests) umsetzbar(*).

Wenn dann der Editor fertig ist (für den sehe ich nur die 3. Phase als relevant an!) und die Änderungsgeschwindigkeit sich stabilisiert hat, wäre es Zeit für das nächste Release.

Wann ist das? Na dann, wenn's fertig ist

Also los, geht vom -Modus zum -Modus über, damit wir und



--
(*) Was ist ein weicher Feature Freeze?
Das letzte Release hat gezeigt, dass ein harter Feature Freeze für uns kein gut gangbarer Weg ist. Daher würde ich gerne einen weichen Feature Freeze probieren - d.h. Implementierung von Features die nur sehr lokale Auswirkungen haben oder nicht über den Umfang eines Bug-Fix hinaus gehen, wären dann weiterhin i.O.

[swiss]

Kurz ein paar Fragen von meiner Seite...

- Wie wird die CV auf dem WG aktualisiert? Direkt über Update oder wieder über cometvisu im Paketfeld? (hängt mit der nächsten Frage zusammen).

- Müsste man für die neue Releasversion ein neues "Handbuch" anlegen um mehrere Versionen bedienen zu können oder überschreiben wir einfach die bestehenden Seiten am Tag X der Veröffentlichung?

- Wie wird die Version heissen? 0.6.3?

[Chris M.]

- Wie wird die CV auf dem WG aktualisiert? Direkt über Update oder wieder über cometvisu im Paketfeld? (hängt mit der nächsten Frage zusammen).

Das fertige nächste Release: wird wohl automatisch drüber installiert.

Test-Pakete für die finale Phase der Entwicklung werden wohl anders laufen (ich stelle mir vor, eine parallele Schine aufzumachen, die sich z.B. unter /visu_test/ installiert.)

Da aber Makki die Pakete baut, wird er sicher hier noch etwas autoritatives sagen können...

- Müsste man für die neue Releasversion ein neues "Handbuch" anlegen um mehrere Versionen bedienen zu können oder überschreiben wir einfach die bestehenden Seiten am Tag X der Veröffentlichung?

Ich sehe hier keinen Grund abwärtskompatibel zu bleiben, d.h. eine Version des Handbuchs wird wohl reichen.

- Wie wird die Version heissen? 0.6.3?

Sind doch einige Features dazu gekommen, d.h. ich überlege bzgl. einer 0.7.0 oder gar 0.8.0
(Da die 3D-Seiten noch nicht wirklich gehen, kann es keine 1.0.0 werden )

Andere Meinungen?

[swiss]

Ok

Also dan beginne ich in den nächsten Tagen mal eine Arbeitskopie des Handbuches unter Labor anzulegen damit ich (und eventuell der eine oder andere Helfer) in Ruhe mit der Aufarbeitung des Handbuches beginnen kann/können.

[StefanW]

Guten Morgen,

Ich sehe hier keinen Grund abwärtskompatibel zu bleiben, d.h. eine Version des Handbuchs wird wohl reichen.

ich würde hier schon einen Grund sehen:

Die (derzeitige) Release-Version der CV ist außerordentlich einfach in der Benutzung. Zwar durchaus eingeschränkt aber dafür mit einem WYSIWYG Editor.

Ich wäre dafür, dieses erste Release als CV-Light zu behalten. Ich fände es sehr wichtig, dass es eine Visu gibt, die fast ohne Einarbeitung zu benutzen ist und binnen zwei Stunden eine brauchbare Visu ergibt. Komplexe Visus bei denen man Tage- und Wochenlang herum malen muss, gibt es schon genug.

Die neue CV-Visu hat einen anderen Editor-Ansatz. Natürlich sehr mächtig und erweiterbarer, aber benötigt ein paar Stunden mehr Einarbeitung, dafür gibt es ausgefeiltere Designs und später dann auch 2D/3D für diejenigen, die unbedingt trotzdem malen wollen.

Die neue CV könnte man doch parallel als "CV Professional" (oder so ähnlich) anbieten.

Insofern wäre aus dieser Sicht ein separates Handbuch / Pfad erforderlich.

lg

Stefan

[swiss]

Ja dass war auch mein Gedanke...

Nicht jeder wird warscheinlich am Tag X auf die neue CV Version umsteigen (wenn warscheinlich auch die meisten).

- Dann könnte das neue Handbuch für grosse Verwirrung sorgen weil dazwischen Welten liegen. Alles was mit Editor zutun hat ist anders.
- Sehr viele neue Widgets und Einstellungen sind dazugekommen.
- Auch ein neues Design (Metal) was nicht abwärts kompatibel ist weil es diverse neue Attribute nutzt. (Lässt sich zwar ändern aber sieht nicht mehr soo toll aus wie auf den bekannten Screenshots)

Die Frage ist, ob man (damit es nicht zu aufwändig wird) sich auf 2 Versionen einigt?

Was meint ihr dazu?

[greentux]

Vorstellbar wäre, die alte Version einzufrieren und "as is" zu kennzeichnen.
Also kaum Support, keine Fixes mehr, erst recht keine neuen Sachen.

[Chris M.]

Ich würde halt ungern zwei (bzw. dann wären es ja sogar drei...) Versionen des Codes in der freien Wildbahn halten, dass wird sonst vom Support vermutlich ein Alptraum.
Deswegen hatte ich mich eher gefragt, wie automatisch das Update auf den neuen Code gehen soll (vgl. aktuell normales Update vs. Kernel-Update).

Von Light und Professional halte ich wenig, da der Code genau dar gleiche ist. Wir haben nur einen alten (per WYSIWG intuitiveren) und einen neuen (per XSD universelleren) Editor.
D.h. wenn, dann haben wir hier ein Doku-Problem das wir lösen müssen (z.B. mit einem Tutorial neben der Referenz).

Und das ich mir langfristig eine WYSIWG-Erweiterung des Editors gewünscht habe, hatte ich ja schon mal geschrieben. Dennoch ist es richtig, erst mal den XSD-Part sauber zu lösen, das andere kann man hoffentlich schmerzfrei für's folgende Release hinzufügen.

[henfri]

Hallo,

ich möchte Stefan beipflichten.
Ich bin sicher, dass es User gibt, die mit der CV mit dem aktuellen Editor nichts anfangen können -mit dem alten aber sehrwohl.

Was spricht dagegen, die Dokumentation mitzuliefern und in wiregateXXXX/visu_light/doc/ zu speichern.

Eine andere Möglichkeit: Kann man nicht den alten WYSIWYG Editor weiter nutzen? Damit kann man die neuen Features zwar nicht nutzen, aber sonst...
Das hätte den Vorteil, dass man nicht mehrere Codes im Umlauf hat.

Dann gäb es auch nur eine Doku, in der dann einmal der WYSIWYG Editor beschriben wird und einmal der neue. Nachteil: Es müssten Features als "Expertenfeatures" dokumentiert werden (eben alles neue, was mit WYSIWYG nicht geht).
Andererseits: Die "light" Version wird ja v.a. von Leuten benutzt werden, die nicht so auf Handbücher stehen ;-)

Gruß,
Hendrik

[greentux]

Ich sehe nicht, das der neue Editor nun sooo kompliziert ist. Das ist in vielen anderen Programmen auch so, das es ein wenig Einarbeitung bedarf (die ersten Seiten werden trotzdem nach 30 Minuten herauspurzeln).

Ansonsten könnte man noch den alten Status forken, bischen aufhübschen und selber betreuen...

[makki]

Also meine Ansicht - bitte nicht als Kritik oder letzte autoritative Meinung speichern - ist:
Es gibt ein Release, das ist sehr stabil und gut! Und das möchte ich im Sinne der Anwender beibehalten, die "einfach nur ein paar Schalter" auf der Visu - mit geringstmöglichem Aufwand - haben wollen (zu dieser Zielgruppe gehöre ich, die 5 Grafiken kann ich mir als iframe einbinden, auch wenns mit Flot natürlich schöner geht)
Das sind die 99% die nicht laut schreien..

Wartungs-Aufwand? =0 Es gab keinen Grund, groben Bug o.ä. da seit ewig was zu drehen (das spricht ausdrücklich für die CV!)

Das nächste wird (teils zu meinem Leidwesen, auch keine Kritik sondern wenn bitte nur Anregung wo man hin will?!) eher ein Malprogramm, wo man mit colspan, rowspan und groups sich die dollsten Sachen machen kann.. Aber gezwungen wird zu "malen". Ist schön, Anwenderwunsch, ganz klar, kommt beim NBF und beim Geek besser an, finde ich auch schön - ist mir *persönlich* aber schon viel zu aufwändig!

Bis wir die goldene Mitte zwischen Visu-malen und meinem Traum vom Auto-Layout gefunden haben, bin ich ganz klar für zwei Versionen, beim jetzigen Release 0.6 gibts wenig zu pflegen, das geht hundertfach, gibt aber halt keine neuen Features.. Gut, ist halt so.
Der überwiegende Wunsch der stillen Mehrheit, die sowas dutzendfach im Feld haben (und damit der Mehrheit der zahlenden Kunden, denn die wollen möglichst wenig Aufwand zahlen müssen) ist jedoch schnelle Einrichtung und einfache Wartbarkeit, darauf konzentriere ich mich dann
Wobei ich ja durchaus was mitnehme, von dem tollen was ihr da macht! Nur so eine config für ein Metal-Design, ganz ehrlich, da braucht man ein freies WE oder so, das war nie mein Ziel, den HS als Sehenscheidentzünder abzulösen

Makki

[Chris M.]

Das nächste wird (teils zu meinem Leidwesen, auch keine Kritik sondern wenn bitte nur Anregung wo man hin will?!) eher ein Malprogramm, wo man mit colspan, rowspan und groups sich die dollsten Sachen machen kann.. Aber gezwungen wird zu "malen". Ist schön, Anwenderwunsch, ganz klar, kommt beim NBF und beim Geek besser an, finde ich auch schön - ist mir *persönlich* aber schon viel zu aufwändig!

Das ist, glaub ich, der Punkt, der noch nicht wirklich angekommen ist: auch aktuelles SVN ist kein zwingendes Malprogramm!
Wenn Du willst, kannst Du, klar - aber wenn Du nicht willst, geht's genau so wie vorher.

Keine colspan und rowspan definiert? Wunderbar, dann macht er das Widget genau eine halbe Seite breit (wie war das noch mal unter 0.6.x? ...)

Meine persönliche Test-Seite für's SVN sieht genau so aus, wie meine täglich genutzte Test-Seite des 0.6 Release - es ist meine persönliche Visu an der Wand und die Config-Dateien sind quasi identisch. (Ich war nicht mal so artig die readonly/writeonly zu übersetzen...)

=> Wenn ein automatisches Skript die Config-Datei übersetzt (und das brauchen wir IMHO zwingend), dann wird ein Anwender den Wechsel nur durch den anderen Editor merken.

Die Zeit einer Visu-Erstellung und Pflege ist bei gleichem Visu-Umgang (d.h. wenn man die neuen Design-Möglichkeiten nicht nutzt) identisch (Annahme: Bedienzeit zwischen altem und neuem Editor ist sehr ähnlich)

[henfri]

Hallo Chris,

ich glaube, du überschätzt da einen großen Teil der Anwender:
Ich kenne viele, die sich beim aktuellen Editor -und das soll wirklich keine Kritik sein- umdrehen und gehen würden.
Das ist einfach nix für die, weil's nach "Programmieren" riecht. Und für die -die Makki ja auch anspricht- wird der alte Editor benötigt.
Dazu hatte ich hier ja einen Vorschlag gemacht:

Eine andere Möglichkeit: Kann man nicht den alten WYSIWYG Editor weiter nutzen? Damit kann man die neuen Features zwar nicht nutzen, aber sonst...
Das hätte den Vorteil, dass man nicht mehrere Codes im Umlauf hat.

Dann gäb es auch nur eine Doku, in der dann einmal der WYSIWYG Editor beschriben wird und einmal der neue. Nachteil: Es müssten Features als "Expertenfeatures" dokumentiert werden (eben alles neue, was mit WYSIWYG nicht geht).
Andererseits: Die "light" Version wird ja v.a. von Leuten benutzt werden, die nicht so auf Handbücher stehen ;-)

Gruß,
Hendrik

[Bodo]

Hoi

Das sehe ich genau so. Der alte Editor sollte erhalten bleiben, sozusagen als Einstieg.

[Chris M.]

ich glaube, du überschätzt da einen großen Teil der Anwender:
Ich kenne viele, die sich beim aktuellen Editor -und das soll wirklich keine Kritik sein- umdrehen und gehen würden.
Das ist einfach nix für die, weil's nach "Programmieren" riecht. Und für die -die Makki ja auch anspricht- wird der alte Editor benötigt.

Ich bin mit der Usability vom neuen auch noch nicht glücklich - hab ich auch schon im Editor-Thread geschrieben - sehe das aber noch also Work-in-Progress an und das Potential, da deutlich nachlegen zu können.
Der zugrunde liegende Ansatz ist auch richtig - auch wenn ich der Meinung war mit dem bestehenden es auch hinbekommen zu können. Das sind aber Programmier-Philosophische Beweggründe und beide haben ihre Berechtigung.

Dazu hatte ich hier ja einen Vorschlag gemacht:

Eine andere Möglichkeit: Kann man nicht den alten WYSIWYG Editor weiter nutzen?

Das wäre auch mein Wunsch - aber der alte Editor hat die Config-Dateien definitiv beschädigt, sobald neue Features drinnen waren. Wie bekommt man das einem Anwender erklärt?

Geben wir dem neuen Editor doch noch etwas Zeit. Das sonstige Release ist ja unabhängig vom Editor - und hier habe ich bisher noch nichts gehört, vgl. mein Ursprungsposting. D.h. wenn das so weiter geht, wird es noch sehr lange dauern, bis es kommt...

PS: Editor Milestone 4 (der nächste) spricht von:

- preview for a selected node without the need of replacing the configuration on the server