Der Weg zum nächsten (0.8.0) Release

[Chris M.]

hausl ist ganz zuverlässig die in der CV zu aktuallisieren - ich bin daher zuversichtlich, dass alle Icons drinnen sein werden, die bis kurz vor dem finalen Release Candidate vorhanden sind.

Übrigens: Icons im Android 2.3 sollten im aktuellen SVN wieder funktionieren.

[MicHau]

hausl ist ganz zuverlässig die in der CV zu aktuallisieren

Schon geschehen, man tut sein Bestes!

Für "nach dem Release" würde ich mir allerdings ein dynamisches Befüllen des Iconhandler wünschen durch Aufruf eines serverseitigen PHP-Skript, das die in einem (oder mehreren) Ordner (meinetwegen auch in der Config definierbar) vorliegenden Bilddateien zurückliefert. Dann würde man sich auch die Updateorgie sparen und böte zusätzlich noch die einfache Möglichkeit für die Verwendung eigener Icons.

[Chris M.]

Eigene Icons sollte schon jetzt gehen, in dem man die im Custom JavaScript Code mit einfügt.

(Und eigentlich sollte im Icon-Handler kein Icon befüllt werden, sondern das in einer extra JS-Datei... Kann aber locker auf nach dem Release warten, das ist nur schöner Wohnen)

[Chris M.]

So, die 0.8.0-RC2 ist draußen

Wenn jetzt keine gravierenden Bugs mehr kommen, bzw. keine weiteren Bug-Fixes (vielen dank an die Zahlreichen Commits der letzten beiden Wochen!), dann könnte diese Version in den nächsen 1-2 Wochen zur finalen 0.8.0 erklärt werden!

[Hannatz]

Der Weg zum nächsten (0.8.0) Release

Welcher SVN-Revision entspricht die RC2? Und gibts irgendwo ne Übersicht des Changelog?

Teste aktuell ein wenig mit der SVN-Version rum, insofern wären diese Angaben recht hilfreich...

Danke & Gruss,
Hannatz

[Chris M.]

Wenn ich 1980 schreibe, ist das zu langweilig. Also lieber Hilfe zur Selbsthilfe:

Die zugrunde liegende Revision, kann man ganz einfach am SVN-Web-Interface ablesen, vgl. /CometVisu/branches

Das ChangeLog als manuelle Zusammenfassung liegt im Paket immer bei. Für den RC2 siehe auch /CometVisu/branches/release_0.8.0-RC2/ChangeLog oder das jeweils neueste natürlich im Trunk /CometVisu/trunk/ChangeLog

Ansonsten kann natürlich dein SVN-Client weiter helfen.

Wenn Du der Entwicklung folgen willst, dann lohnt es sich auch, die SVN-Commit-Mailingliste zu abonieren: Open Automation / Mailing Lists

[ctr]

Um hier nochmal die ganze Diskussion wegen backend mal zu kanalisieren:

Wir haben hier zwei völlig unterschiedliche Zielgruppen:
1) (WG oder andere, sicher meist WG) Nutzer die bereits eine 0.6.x haben und damit auch funktionierende backends
2) Neu-Benutzer, sowohl WG als auch andere. Für WG-Nutzer wäre es ja nun einfach zu sagen installiert euch vorher das alte Paket, damit fallen sie nicht mehr in die Kategorie 2 sondern 1.

Die Paketierung bzw. Distribution wird für beide Fälle grundverschieden sein müssen, leider.
Für nicht-WG Nutzer wurde ja eingangs schon erwähnt, dass noch l,r,w irgendwo herkommen müssen, den Ansatz diese vorkompiliert irgendwo vorzuhalten finde ich nicht erstrebenswert. Ich denke da die Nutzung der CV auf nicht-WGs derzeit sowieso mit einigem Basteln verbunden ist, ist das manuelle kompilieren von eibread/write nun auch nicht mehr so viel...

Für die Zukunft (aber das gehört vielleicht nicht unbedingt in die 0.8.0 Release Diskussion) sehe ich einen mittel- und einen langfristigen Ansatz:
Mittelfristig: Ausplittung der CV in zwei Paket, die eigentliche CV und das Backend
Langfristig: Ersatz/rewrite des Backends (wer sich mal die Antworten von AKoegler angesehen hat *warum* er das nicht mit in die bcu-sdk aufnimmt weiß wovon ich rede)

Durch den mittelfristigen Ansatz wären wir erstmals in der Lage WG und nicht-WG Nutzer gleich mit CV zu versorgen...

[swiss]

Ja ich bin auch der Meinung, dass man das Backend in ein eigenes Paket stecken sollte. Denn das Frontend kann ja einfach wie bei der SVN Version immer wieder in der aktuellen Version über die alte Version gebügelt werden. Das Updatescript richtet dann den Rest

[Chris M.]

So, die RC3 ist draußen - und ich hoffe stark, dass das die finale ist...

[MG8]

Installation 0.8.0 RC3

Hallo zusammen, ich bin relativ neu hier und würde gerne wissen wie ich den RC3 auf mein Wiregate bringe. Das Download habe ich durchgeführt, die Version 0.6.3 habe ich wie es beschrieben ist installiert und die Visu kann aufgerufen werden. Was muss genau nach einander gemacht werden, wo muss was kopiert, konifiguriert, ... werden?
Gruß Micha

[swiss]

Ohne Paket und ohne fertige Anleitung/eigenes Linuxwissen ist das nicht ganz einfach zu erklären. Zumal intern noch nicht 100% klar ist, wie das Verfaren genau sein soll.

Du kannst mit etwas Linuxwissen einfach das RC3 von SF herunterladen und -> WICHTIG!: In ein eigenes Verzeichniss unter /var/www/ entpaken. Der Vorteil, da du das Releas 0.6.2 installiert hast, brauchst du dich nicht um das Backend zu kümmern. Das erspaart dir schon einiges

[swiss]

Das Thema Update ist in meinen Augen noch nicht ganz zufriedenstellend geklärt. Zumal es auch eine Lösung sein sollte die in Zukunft konsistent ist...

Ein Paket hat zwar Vorteile aber auch Nachteile... Zumal die Pakete auch auf einem "paketserver" bereitgestellt werden müssen. Wenn ElabNet das also nicht hostet, kann das Paket auch nicht einfach über die Updatefunktion im Webmin installiert werden.

Mir schwebt ein Lösungsansatz vor, bei dem wir von niemandem abhängig sind...

Hier mal meine Idee bevor sie in der Luft zerrissen werden kann:

Mit der CV wird im Visuverzeichniss ein bash script mitgeliefert, dass sich als erstes eine bestimmte Datei ("index") aus dem SF Repo holt in der der Name des aktuellen Releas steht. Mit dem Namen wird das entsprechende Paket automatisch von SF heruntergeladen und entpackt. Das setzen der Rechte kann auch gleich das bashscript erledigen. Dieses Bashscript könnte man dann theoretisch sogar noch über ein PHP aufrufen und damit den gesammten Updateablauf für den Endanwender über den Webserver zur Verfügungstellen. Somit braucht der User nur noch das PHP aufrufen und bestätigen, dass er aktualisieren möchte.

Für die Entwikler wird der Aufwand zum verteilen auch wesentlich kleiner...

Einfach ein neues Releas Verzeichniss im Branches erstellen und in der "indexdatei" die neue Version angeben. Schon kann sich jeder User der möchte wieder über das gleiche Script ohne weiteren Eingriff die nächste Version herunterladen...

So könnte man das komplet SF intern lösen und wäre absolut unabhängig vom paketmanagement und obskuren Befehle auf der Konsole. Und das kann jeder egal ob WG oder nicht gleichermassen verwenden um seine CV Version hochzuziehen.

[netzkind]

Hi Michael,

ich hab mir das Thema jetzt noch mal angesehen.

Die Zeitbezüge zu den Zeitpunkten stimmen ja auch, nur die Darstellung von counter rrd mit steps ist falsch.
Ich habe versucht das nochmal im angefügten Screenshot darzustellen.

Hintergrund:
jeder Punkt im Diagramm besteht aus Wert und Timestamp.
Die Tools im Wiregate (bspw. drraw) zeichnen zwischen zwei Werten erst eine vertikale Linie, und dann eine horizontale.
Bei flot (das ist die Engine die dem diagram-Plugin zugrunde liegt) wird nun laut Doku immer erst eine horizontale, und dann eine vertikale Linie gezeichnet.
Klardeutsch: drraw springt erst zum Wert, und zeichnet dann eine grade Linie zum Datum - flot zeichnet erst eine Linie zum Datum, und sprint dann zum Wert.

Man müsste also flot belügen. Also jeden Datenpunkt um einen Wert X zurückdatieren, damit flot den Wert für Dienstag nicht als "Dienstag abend", sondern als "Dienstag früh" sieht. Das ist so schwer machbar, deshalb würde ich vorschlagen, einfach den ersten Value fallen zu lassen, und jeden nachfolgenden Wert den Timestamp des vorherigen Values zu geben.

Beispiel:

Original:
wert1:12.10. 00:30
wert2:13.10. 00:30
wert3:14.10. 00:30
...

Was flot sieht:
wert2:12.10. 00:30
wert3:13.10. 00:30
...

Der erste Wert ist weggeworfen, und der höchste Timestamp ist der vorletzte.

Die Frage ist: auf welcher Grundlage entscheidet das Diagramm-Plugin, wann es flot belügen soll und wann nicht? Einfach immer wenn steps = true ist? Noch ein zusätzliches Konfigurationsfeld einbauen?

[Chris M.]

Das Thema Update ist in meinen Augen noch nicht ganz zufriedenstellend geklärt. Zumal es auch eine Lösung sein sollte die in Zukunft konsistent ist...

Wobei ich nicht weiß, ob wir da zu 0.8.0 schon die richtige Lösung bekommen können.

Was ich aber gerade gemacht hab:
Die Demo-Configs sind nun in einem extra Unterordner, d.h. ein Skript sollte sich nun deutlich leichter tun die User-Configs zu übernehmen.

Ein Paket hat zwar Vorteile aber auch Nachteile... Zumal die Pakete auch auf einem "paketserver" bereitgestellt werden müssen. Wenn ElabNet das also nicht hostet, kann das Paket auch nicht einfach über die Updatefunktion im Webmin installiert werden.

Ein WG Paket könnten wir evtl. unter cometvisu.de hosten. Einfach die Verzeichnisstruktur passend anlegen (wäre eine Weiterführung der anderen Diskussion...)

Mir schwebt ein Lösungsansatz vor, bei dem wir von niemandem abhängig sind...

Hier mal meine Idee bevor sie in der Luft zerrissen werden kann:

Mit der CV wird im Visuverzeichniss ein bash script mitgeliefert, dass sich als erstes eine bestimmte Datei ("index") aus dem SF Repo holt in der der Name des aktuellen Releas steht. Mit dem Namen wird das entsprechende Paket automatisch von SF heruntergeladen und entpackt. Das setzen der Rechte kann auch gleich das bashscript erledigen.

Das können wir natürlich machen. Wobei da immer die Frage ist, ist es leichter ein universelles Skript zu schreiben oder eine fast universelle Doku und den Rest per Forum abzuhandlen...

Dieses Bashscript könnte man dann theoretisch sogar noch über ein PHP aufrufen und damit den gesammten Updateablauf für den Endanwender über den Webserver zur Verfügungstellen. Somit braucht der User nur noch das PHP aufrufen und bestätigen, dass er aktualisieren möchte.

Das wäre durchaus eine Möglichkeit - aber die 0.8.0 ist dafür sicher zu kurzfristig.
Verbietet aber keine die nächste Version kurz darauf zu veröffentlichen

[Chris M.]

So, die 0.8.0-RC4 lädt nun gerade hoch.

Wenn innerhalb der nächsten Woche keine gravierenden Bugs gefunden und/oder gefixt werden, würde ich die gerne am nächsten Wochenende zur finalen Datei erklären.

Widerspruch dazu bitte hier im Thread