- √ - CometVisu - Öffentlicher Beta-Test: Vorbereitungen

[swiss]

OK. Dann werde ich warscheinlich bei Gelegenheit mal noch einen "LABOR " bereich im SF-Wiki anlegen in dem die Widgetbeschreibungen der vorabversionen liegen. Bei der Veröffentlichung braucht es dann nur noch eine Ergänzung der Widgetliste.

[chriss1980]

Wird es dann weiter so sein, dass neue Widgets erst hier im internen Beta-Test getestet werden bevor sie in ein offizielles Update kommen?

Eine andere Frage, unabhängig vom Freigabemodus: wäre es nicht möglich Widgets in eigene Dateien zu stecken, anstelle aller Widgets in einer großen Datei? Ggf. in einem Unterordner, von dem alle .js automatisch eingebunden werden? Das könnte Pflege, Freigabe, Austausch usw. vereinfachen. Ähnlich wie die Plugins halt...

[Chris M.]

Warum macht setzt jetzt die FRs alle auf "Resolution: later"? Wenn man die Group mal als Version interpretiert, dann stimmt doch "after 0.6.0", egal, wann es reinkommt.
"later" hat sowas von "ganz viel later, eigentlich nie"

Man kann hier sicher verschiedene Phiolosophien fahren.

Für mich relevant: das "later" sieht man direkt, das "after 0.6.0" nur wenn man den Bug offen hat.

Jetzt weiß jeder, der den Bugtracker öffnet, dass diese Bugs bekannt sind, aber halt eben nicht jetzt kommen. Sondern eben nach der 0.6.0.

Bald werden wir eh neue Stati einführen, z.B. 0.7.0 oder 0.6.2 - und dann kann man auch das "later" in "accepted" o.ä. ändern.

Wird es dann weiter so sein, dass neue Widgets erst hier im internen Beta-Test getestet werden bevor sie in ein offizielles Update kommen?

Sicher ist, die werden erst mal in der SVN Version sein und nicht im Paket.

Ich würde aber ungern einen parallelen Entwicklungspfad öffnen wollen. Im Zweifel gibt man dem Widget einfach eine passende Maturity und das ist für die meisten beim nächsten Service-Release unsichtbar.

Den langen Release-Zyklus wie jetzt will ich auch nicht wieder wiederholen. Das soll IMHO in Zukunft schneller und leaner gehen - dennoch ist er jetzt auch richtig so. Wir haben nämlich hohe Erwartungen und müssen sehr mit dem ersten Eindruck aufpassen.
Daher ist es auch gerechtfertigt z.B. auf die Doku zu warten.

Höchstens für die 1.0.0 stelle ich mir wieder eine so lange Phase vor.

Eine andere Frage, unabhängig vom Freigabemodus: wäre es nicht möglich Widgets in eigene Dateien zu stecken, anstelle aller Widgets in einer großen Datei? Ggf. in einem Unterordner, von dem alle .js automatisch eingebunden werden? Das könnte Pflege, Freigabe, Austausch usw. vereinfachen. Ähnlich wie die Plugins halt...

Jain.

Du kannst per JavaScript nur schwer sagen "include alle Dateien in diesem Verzeichnis", da würde man, um sauber zu sein, Logik auf dem Server brauchen. Außerdem ist das langsam bzw. wird beim Optimieren von JavaScript bewusst alles in eines gepackt.

Eine Logik auf dem Server will ich nicht (Editor ist als Spezial-Fall ausgenommen), da das ganze auch z.B. auf einer Fritz!Box laufen können soll die kaum Ressourcen hat. Insbesondere keinen RAM wo man z.B. mit PHP um sich werfen sollte.

Die einzige Lösung wäre im Paket-Build-Prozess aus den vielen kleinen JavaScript Dateien eine große, gepackte zu machen. (Was, auch ohne Aufteilen der Widgets Sinn macht und angegangen werden muss).
Problem dabei ist jedoch, dass man nun zwei verschiedene index.html braucht - eine für SVN Benutzer und eine für Paket Benutzer.
=> Machbar, aber zu viel Aufwand für den jetzigen Stand.

[swiss]

Kann man es denn nicht einfach so weiter laufen lassen wie es bis jetzt war? Nach dem Releas wird weiter entwikelt (BUG fix) und neue Widgets fliessen in das Paket ein, wenn sie freigegeben wurden.

Wer die Comet auf eine Fritzbox installieren will (und kann) ist mit der Konsole so vertraut, dass er die nichtbenötigten Widgets einfach aus der structur_pure.js und den Verzeichnissen löschen kann. Dazu kann man notfalls auch einen kleinen Handbuchbeitrag verfassen, damit die jenigen die es interessiert auch wissen wo sie was löschen müssen.


Die grosse Masse die auf dem WG die CometVisu installieren, sollten Zugang zu allen zukünftigen Widget's erhalten ohne die Konsole bemühen zu müssen.

[Chris M.]

Kann man es denn nicht einfach so weiter laufen lassen wie es bis jetzt war?

Nö, ich will nicht wieder in einen Release-Branch (z.Zt.: HEAD) und einen Zukunftsentwicklnugs-Branch (Post-0.6.0) aufsplitten.
Das wird IMHO zu viele Ressourcen binden.

Nach dem Releas wird weiter entwikelt (BUG fix) und neue Widgets fliessen in das Paket ein, wenn sie freigegeben wurden.

Genau so ist's geplant.

[swiss]

Ich meine dass nicht unnötig kompliziert. Eher in der Art. Es gibt für neue Widget's weiterhin interne BETA Test's hier. Die Neuen Widgets werden einfach als Plugins zum Download bereitgestellt und jeder BETA-Tester kann die bei sich von Hand einbinden und testen. Wenn keine Fehler auftreten wird das Widget einfach in das nächste Update mit übernommen. Dann gibt es nur noch EINE Version zu pflegen. Der rest kann man den BETA-Testern zumuten.

[swiss]

So die Doku befindet sich im Endspurt. Nur die Seite XML-Elemente ist noch eine Baustelle die ich am Sonntag abschliessen werde. Ich bitte alle die Zeit und Lust haben nochmal über die Doku zu schauen und Fehler zu melden oder gleich zu korrigieren.

Gibt es zu der Doku noch etwas, dass vergessen wurde? (Anregungen Wünsche)?

[greentux]

mach ich dann heute am späten Abend mal...


@chris: meiner Meinung nach wird man um das absplitten von releasebranches nicht umhin kommen. ich weiss, ressourcenlage ist nicht so dolle. aber wenn man quasi die devs daran hindert, schonmal die "coolen" widgets von morgen einzuchecken, steigert das nicht die motivation...
der releasebranche ist ja dann direkt nach release auch nicht mehr lange zu pflegen...

[Chris M.]

meiner Meinung nach wird man um das absplitten von releasebranches nicht umhin kommen. ich weiss, ressourcenlage ist nicht so dolle. aber wenn man quasi die devs daran hindert, schonmal die "coolen" widgets von morgen einzuchecken, steigert das nicht die motivation...

Hintergrund ist ein anderer: Wenn jeder im HEAD arbeitet - wer testet dann den Release-Branch?

Aber ich denke in Zukunft wird das ganze deutlich entspannter sein. Die 0.6.0 hat einfach erhöhte Anforderungen. Bei den nächsten Versionen sollte man direkt aus HEAD das Release machen können. Ggf. mit einer Woche Freeze, das sollte jeder aushalten, insb. da man ja erst mal in der structure_custom.js für sich entwickeln kann, bevor man das hochläd.

[greentux]

Tja, aus meiner Erfahrung heraus kann man Entwickler nicht wirklich dazu zwingen, den stable lange zu testen Dat machen die einfach nicht Umso wichtiger, vl. automatisiert zu testen. Hat da jemand Erfahrung in Zusammenhang mit Javascript?

Auch aus HEAD releasen mit freeze geht. Es muss nur klar sein, das dann Bugfixes zum Release relativ schwierig sind. Brauchts bis 1.0 vermutlich aber auch nicht.

[makki]

Naja, das wird sich einspielen&zeigen müssen denke ich alles kann man im Vorfeld eh nicht lenken
Die aktuelle Vorgehensweise - alles ist dabei aber nur die Plugins die als "fertig"+unintrusiv oder essentiell/cool erachtet werden in der Default-config - ist denke ich nicht falsch. Für zig branches & releases fehlts schlicht, selbst wenn man wollte..
Ich bin jedenfalls gegen zig branches o.ä., das kostet IMHO einfach zuviel Zeit. Ergo, würde derzeit sogar soweit gehen das es Bugfixes auch nur mit dem nächsten Major-release gibt; mag hart klingen, aber wie sollen wir sonst realistisch vorankommen..


ggfs. für andere Plattformen was abzuspecken ist dann Aufgabe des dortigen Packagings (* es gibt ja schon ein OpenWRT-packerl, keine graue Theorie ), so ist das auch üblich denke ich.. z.B. kein PHP=kein Editor, ist dann eben so, wenn man 4MB NAND statt 4GB CF-Flash hat..

Umso wichtiger, vl. automatisiert zu testen. Hat da jemand Erfahrung in Zusammenhang mit Javascript?

Das wäre indeed eine sehr interessante Sache, wenn da jemand ein paar Erfahrungen/Herangehensweise hätte!
Hab da auch schon an einigen anderen Stellen angefangen (deswegen kann ich mancherorts mittlerweile ganz kurz&knapp sagen: ich bin mir sicher das es geht! - ohne es vorher nochmal händisch zu prüfen )
Technisch müsste sich das IMHO zumindest für die Transforms (hier KNX Wertempfang/Anzeige/Versand) und Funktion der "core"-widgets machen lassen(?); Layout/Design mit automatisierten Tests zu prüfen, dürfte nahe unmöglich sein, aber das erste wäre schonmal ein guter Schritt.

Makki

[greentux]

Es wäre ja nur ein Branch, nämlich immer der letzte "stable" gewesen. Aber ja, für ein ambitoniertes OSS Projekt ist es sehr legitim ohn Branches vorzugehen. Wenn, wer auch immer, mal CV bei Kunden supporten möchte, wird man dann nicht mehr drum herumkommen.
Gut, dann wäre der Punkt schonmal fix

[makki]

Ich hab schon den Anspruch, das es auch bei "echten" Kunden läuft und kenne mittlerweile glaube ich auch den harten SI-Alltag halbwegs, zumindest von der Ehrentribüne
Aber wir alle dürften den Anspruch haben, primär funktionierende Software auszuliefern, keine Bugfixes (ab sagen wir mal 0.8 dann ganz ganz ernst) Klar werden die auch vorkommen, aber nicht die Regel sein und nicht kriegsentscheidende Dinge betreffend (sowas ob ein switch geht oder nicht..)

Wenn ich mir da jetzt grad mal die Alternativen in meinem Keller ansehe und welche Bugfixes ich da wann für was bekommen habe, dann ist die CV 16.3p499 und verdammt weit vorn

Makki

[greentux]

Naja, aber wenn man entwickelt, greift man meist invasiv in den zur Freigabe getesteten Code ein. Daher kann man die Qualität auch nicht gleich bewerten. Wenn ich nun in der Zeit aber eine Bugfixversion rausschicken möchte (und sei es nur, das da 5 Typos in der Visu sind), dann habe ich keine Chance.

Es sei denn, die freigegebene Version hat einen Branch. Dann bekommt der den Bugfix und aus die Maus. Die Refaktorierung hat ja dort nicht stattgefunden. Die Qualität ist leicht feststellbar.

Das hat sich als notwendig erwiesen, wenn man Produkte an Kunden ausliefert und zeitnah Bugfixes liefern können muss. Das passiert ja hier derzeit nicht. Und muß es auch nicht.

[makki]

Eben..Ich weiss aber ganz genau was du meinst! Ich "verwalte" neben der CV auch noch - sagen wir mal Mutationen - von seltenen Exemplaren owfs, eibd & Co, wo ich in 100 Jahren keinen Branch für bekomme
Ich sehe da bei der CV aktuell jedenfalls kein Problem. Lieber einfach&direkt.

Makki