Wechsel der Eintwicklungsplattform!

[Chris M.]

• Der Aufbau des DOM ist bei vielen Widgets ziemlich langsam (im Bereich von 1-2 Sekunden auf meinem i7 im schnellen Chrome) - vermutlich weil so oft Parse HTML aufgerufen wird

Spontan würde mir dazu als Lösung einfallen [...]

Um Performance-Disukssionen aus diesem Thread heraus zu halten (hier sollte es nur um das Verhalten bei vielen GAs gehen), habe ich dazu einen neuen Thread gestartet: https://knx-user-forum.de/cometvisu/...rformance.html

Ach da hätte ich auch noch einen kleinen Vorschlag bzgl. der Template-Engine ... Verwendung von Templates für die Ausgabe der Widgets. So kann man sich die HTML-Ausgabe noch ein wenig selbst anpassen (wenn man das möchte).

CometVisu-Plugins darfst Du gestalten wie Du willst (bei Widgets sind wir etwas restriktiver). D.h. eine Überladbarkeit per prototype wäre da durchaus möglich.
Wenn ich das so umsetzen kann, wie es mir gerade vorschwebt, müsste in Zukunft ein Widget oder Plugin einfach einen String mit allen HTML-Elementen zurück geben und die Pro-Instanz-Daten liegen in einer getrennten Datenstruktur. Gerade das sollte sich leicht überladen lassen.

Wenn ich die Seufzer von Chris richtig interpretiere, dann braucht es - neben guten Ideen - vor allem Entwickler welche die Sache voranbringen.

Unbedingt!
Und auch Designer/Künstler/Grafiker (gerne auch alles in einem ).
Und sicher auch andere Professionen die mir spontan nicht einfallen aber trotzdem wichtig sind!

Ich sehe folgende Möglichkeiten, die Situation zu ändern:

Variante 1: [...]
Variante 2: Ihr spenden freiwillig (über Support-Stunden in unserem Shop) und ich setze Entwickler zum Selbstkostenpreis daran. Wer jetzt meint, dann gebe ich halt 20.- EUR: unter 100 EUR pro Spende brauchen wir nicht drüber zu reden. Gute Entwickler sind unter 40 bis 70 EUR pro Stunde (Brutto) nicht zu bekommen.

Hier gibt es inzwischen eine weitere interessante Variante dazu: Crowdfunding!
D.h. wenn es ein Feature o.ä. gibt, dass viele interessiert und jeder bisschen Geld spendet, kann so in Summe trotzdem genug zusammen kommen.

Ganz für Umme gibt's das trotzdem nicht: das muss jemand organisieren:

• Thema identifizieren
• Geld sammeln
• Entwickler beauftragen

Variante 3: Es raffen sich freiwillige Entwickler auf welche die Comet Visu voranbringen. Die Backends und die Frontends müssen überarbeitet werden, um die Ansprüche von morgen auch befriedigen zu können. Das wäre die kostengünstigste Variante. Also los, meldet Euch bei Chris.

Gerne!

Ich hät's eigentlich mal in einem anderen Thread schreiben wollen (hier ist's schon etwas OT), aber für ein erstes Stimmungsbild ist's i.o., denke ich:
Wie seht ihr einen Wechsel des Verwaltungssystems? (Hintergrund: ich bin mit SourceForge in der letzten Zeit nicht mehr sonderlich zufrieden; GitHub wäre da natürlich eine offensichtliche Alternative)
- Gute Idee, die dank Git mehr Entwickler anziehen kann?
- Egal?
- Schlechte Idee, SVN funktioniert ja zuverlässig und SF wird die Probleme schon in den Griff bekommen?

[MicHau]

Wechsel der Eintwicklungsplattform?

Wie seht ihr einen Wechsel des Verwaltungssystems? (Hintergrund: ich bin mit SourceForge in der letzten Zeit nicht mehr sonderlich zufrieden; GitHub wäre da natürlich eine offensichtliche Alternative)
- Gute Idee, die dank Git mehr Entwickler anziehen kann?
- Egal?
- Schlechte Idee, SVN funktioniert ja zuverlässig und SF wird die Probleme schon in den Griff bekommen?

Ja bitte, ich hätte es in Kürze auch mal in einem Thread losgelassen, dass es Zeit wäre, auf Github umzusteigen. Meiner Meinung nach macht es das Beitragen zu einem Open Source Projekt mit seiner Infrastruktur wesentlich einfacher. Außerdem sind die Vorteile von Git gegenüber SVN einfach zu deutlich, wenn man sich erstmal daran gewöhnt hat (ich gebe zu, dass es bei mir auch ein bisschen gedauert hat und anfangs etwas merkwürdig war).

Also von mir deutliche Zustimmung

[mivola]

wenn man sich erstmal daran gewöhnt hat ...

So ging/geht es mir auch. Wir haben in der Firma mittlerweile auch einen Teil umgestellt. Und die (persönliche Workflow-) Umstellung ist mMn wesentlich größer als damals von CVS zu SVN...

Zum Thema Geld/Crowdfunding: sicherlich würde ich auch gern etwas spenden um die CV weiterzuentwicklen bzw entwickeln zu lassen. Allerdings nicht in den von Stefan genannten Dimensionen - dazu ist der aktuelle Stand für mich persönlich einfach "zu gut". Alles was jetzt noch kommt ist für mich Spielerei/Sahnehäubchen. Die Investition von Zeit und Können ist leider nur begrenzt möglich - das kennen sicherlich alle die hier mitlesen/schreiben ...

VG
Micha
PS@Stefan: macht es evtl Sinn die Diskussion über Geld/Git in einen neuen Thread zu verschieben um hier weiterhin das eigentliche Problem zu diskutieren?

[Chris M.]

So, leider gibt das Form (zumindest mir) keine genaueren Moderations-Rechte um die drei durcheinander laufenden Themen sauber zu separieren.
Ich hab mein bestes probiert - notfalls bitte einfach in den drei relevanten Threads nachlesen:

https://knx-user-forum.de/cometvisu/...nzahl-gas.html
https://knx-user-forum.de/cometvisu/...plattform.html
https://knx-user-forum.de/cometvisu/...oerderung.html

[JNK]

Ich habe in letzter Zeit eher wenig zur CV beigetragen, würde aber ganz deutlich auch den Umzug zu github/git unterstützen. Völlig dran gewöhnt habe ich mich auch noch nicht, aber Pull-Requests etc. sind einfach deutlich angenehmer.

Gruß,

der Jan

[ctr]

bin auch für einen Umzug zu Github!

[dombn]

+1 GitHub

[Chris M.]

OK, wenn jetzt nicht noch jemand einen Showstopper mitteilt, schau ich mir mal an was bei GitHub so geht.

[Chris M.]

So, ich hab jetzt mal den GitHub-Importer ausprobiert.

=> Das Repository liegt jetzt unter https://github.com/CometVisu/CometVisu

=> Bitte nichts mehr bei SourceForge einchecken (Betrifft erst mal nur die CometVisu, alle anderen Teilprojekte von OpenAutomation bleiben erst mal auf SourceForge)
=> Für alle bestehenden Autoren: bitte teilt mir eueren GitHub Namen so wie den SourceForge Namen mit. Ich glaube die kann ich noch irgendwie verlinken...

Da ich Git und GitHub noch nicht wirklich kann, habt Nachsicht

[tht]

Auch wenn ich nicht der maintainer bin und nichts aktiv zum Code beitrage eine Anregung/ein Hinweis:

Bei git und svn können sich die Workflows unterscheiden (man kann mit git auch wie mit svn arbeiten, ob es sinnvoll ist?), die gebräuchlichsten bei git sind "all to master" oder gitflow.

Beide haben Vor- und Nachteile, aber es sollte möglichst früh geklärt sein wie gearbeitet werden soll und dann auch konsequent umgestellt werden.

[makki]

Die Sachen sind fast alle anders, das ist erstmal ziemlich nervig und eine Lernkurve.

Aber auch von mir (trotzdem oder deswegen)
+1 für GitHub

Makki

[MicHau]

Bei git und svn können sich die Workflows unterscheiden (man kann mit git auch wie mit svn arbeiten, ob es sinnvoll ist?), die gebräuchlichsten bei git sind "all to master" oder gitflow.

Beide haben Vor- und Nachteile, aber es sollte möglichst früh geklärt sein wie gearbeitet werden soll und dann auch konsequent umgestellt werden.

Ja, ich plädiere für gitflow. Damit wäre sehr deutlich, was wie in den Code einfließt. Außerdem erleichtert es ungemein das Bugfixing von Releases. Aktuell wird ja immer im Master weiterentwickelt, und das Bugfix-Release würde auch alle bisher neu entwickelten Features beinhalten. Das ist mehr als suboptimal meines Erachtens.

Es gibt sicherlich auch andere Varianten, die einem das sichere Hantieren mit Releases und Features/Bug-Fixes ermöglichen würden. In jedem Fall brauchen wir, wie Thorsten schon schreibt, ein klares Statement, wie entwickelt werden soll. Und das sollte dann auch hier in die Readme an prominenter Stelle eingefügt werden, damit jeder Bescheid weiß.

[tht]

Da wir allerdings nicht so schnell ein neues Release rausgeben können (vgl. aktuellen Code-Umbau für mehr Performance)

Auch wenn ich als nicht-Entwickler mich in den Entscheidungsprozess nicht einmischen wollte:
Genau in diesem Szenario würde Gitflow eine seiner Stärken ausspielen. Der Code-Umbau würde in einem Feature-Branch von develop laufen und die Releasefähigkeit nicht beeinflussen. Für den Hotfix würde ein Branch von Master erzeugt, der am Ende in master und develop germerged werden würde.

Auch wenn es etwas Bürokratie bedeuten und Disziplin von allen Devs erfordern würde, rate ich euch dringend zu einem sinnvollen Workflow, um euch nicht selbst in den Fuß zu schießen!

[swiss]

Sorry wenn ich hier kurz leicht OT werde aber da ich mich schon wegen Doku und Support mit der SVN Version beschäftige, mit den Repo's aber sonst nix am Hut habe, tat ich mich mit der Umstellung etwas schwer bis der Checkout wieder funktionierte. Da ich warscheinlich nicht der einzige "Nicht Programmierer" bin der die aktuelle SVN verwenden möchte hier mal der aktuelle checkout Befehl für die Konsole:

cd /var/www/

danach

svn co https://github.com/CometVisu/CometVisu/trunk/src/ visu_svn_git

visu_svn_git kann dabei ein beliebiger anderer Verzeichnissname sein der unter var/www/ noch nicht existiert

[Chris M.]

Bei git und svn können sich die Workflows unterscheiden [...], die gebräuchlichsten bei git sind "all to master" oder gitflow.

Beide haben Vor- und Nachteile, aber es sollte möglichst früh geklärt sein wie gearbeitet werden soll und dann auch konsequent umgestellt werden.

Man lernt halt nie aus...

Ja, ich plädiere für gitflow. Damit wäre sehr deutlich, was wie in den Code einfließt. Außerdem erleichtert es ungemein das Bugfixing von Releases.
[...]

In jedem Fall brauchen wir, wie Thorsten schon schreibt, ein klares Statement, wie entwickelt werden soll.

Ich hab mal mir mal den erst besten Google-Link zu "gitflow" durchgelesen, da ich das nicht kannte (https://www.atlassian.com/git/tutori...ring-workflows)

Wenn ich es richtig verstanden habe, dann sehe ich in gitflow durchaus Vorteile - allerdings mit dem Nachteil, dass jeder Schreibzugriff zum Haupt-Repository (CometVisu/CometVisu) braucht, nicht?
"Jeder" ist zwar relativ, da wirklich jeder forken könnte und dann zumindest "Haupt-Entwickler" mit Schreibzugriff das hinein mergen können. D.h. einer der Haupt-Vorteile der verteilten Entwicklung (man kann mitmachen ohne erst mal irgendwo Zugriff zu bekommen) wäre zumindest halb gegeben.

Intuitiv war ich eher von einem Modell ausgegangen, dass auf der Seite als "Forking Workflow" beschrieben wurde.
Da ist nun wirklich jeder gleichberechtigt und ein (bzw. einige "wenige") würden die Änderungen in's Haupt-Repository mergen. Dabei könnte man ja durchaus eine Branch-Verwaltung ähnlich wie bei gitflow einhalten...

Wie sollen wir uns nun entscheiden? Wer kann hier beraten?

Wichtig sind mir im wesentlichen:

• Minimale Einstiegshürde für neue Entwickler (am besten ohne das Gewähren von speziellen Rechten)
• Minimalen Aufwand für den Maintainer (aktuell ich, aber ich teile gerne die entsprechenden Rechte):
  • insbesondere möglichst keine Konflikte die zu lösen sind(*).
  • Und solange mich kein gutes Tool unterstützt möglichst Point&Click auf der GitHub Homepage (ich entwickle zu selten, als dass ich hier auf der Kommandozeile arbeiten möchte...)
  
  

Und da ich schon gesehen habe, dass das hier gut funktionieren kann, wäre ein erweiterter Wunsch:

• Möglichkeit zum Peer-Review

Sorry wenn ich hier kurz leicht OT werde aber da ich mich schon wegen Doku und Support mit der SVN Version beschäftige, mit den Repo's aber sonst nix am Hut habe, tat ich mich mit der Umstellung etwas schwer bis der Checkout wieder funktionierte. Da ich warscheinlich nicht der einzige "Nicht Programmierer" bin der die aktuelle SVN verwenden möchte hier mal der aktuelle checkout Befehl für die Konsole:[...]

Ich hatte schon erwartet/befürchtet dass so ein Beitrag kommt

Bevor wir hier eine offizielle Empfehlung geben, würde ich das mit dem Workflow klären wollen - denn davon wird die Empfehlung abhängen

Und gerade zum reinen Lesen ist git wohl auch nicht wesentlich komplizierter als svn, d.h. ich würde dann durchaus git als Client empfehlen und nicht svn.

--
(*) Ich hab bisher erst zwei gehabt (teilweise zum Üben bewusst provoziert) - und das Lösen war kein Spass. Evtl. kann mir jemand ein gutes Tool für Linux (KDE) empfehlen.