Erweiterung/Support io_fhem.js

[dev0]

Ende August wurde der FHEM Treiber für Smartvisu von jpawlowski (aka Loredo?) in das SV Repository eingecheckt. Seit dem gab es weitere Commits, die den Treiber angepasst haben. Meines Wissens nach ist der Treiber hier im Forum von HCS (und herrmannj?) entwickelt worden. Sind diese Änderungen abgesprochen oder braut jeder sein eigenes Bierchen und Änderungen werden ohne weitere Tests und Koordination von den SV Maintainern übernommen?

Sollte meine Vermutung zutreffen, dass diese Änderungen nicht abgesprochen sind, dann habe ich kein gutes Gefühl dabei und fände es gut, wenn wir eine Vorgehensweise finden, die die Stabilität, Weiterentwicklung und den Support des Treibers sicherstellt.

Meinungen? Fakten?

[HCS]

Meinungen? Fakten?

Fakten
- Den Treiber habe ich damals geschrieben
- Dass der Treiber Bestandteil von SV2.8 wurde, habe ich auch erst kürzlich zufällig entdeckt
- Es wurden wohl irgend welche Anpassungen für SV2.8 gemacht, aber ich habe es mir noch nicht angeschaut, was und warum
- Mit mir hat niemand etwas abgesprochen

Meinungen
Habe ich noch keine so richtige.
Aber eigentlich ist es mir aktuell auch recht egal. An fronthem tut sich nichts, was zu Änderungen am Treiber führen würde, es stehen keine Problem an, die im Treiber erledigt werden müssten und irgend welche SV2.8 Anpassungen wurden von den SV-Leuten, denen der Treiber nun scheinbar gehört, gemacht.

Aber evtl. weiß ja herrmannj noch was dazu.

[HCS]

Da steht es ja, wie es jetzt ist:

The only thing to change should be the driver.js. The one for FHEM in this repository should be up-to-date as @rammann and @jpawlowski maintain this one.

https://github.com/Martin-Gleiss/smartvisu/issues/103 ganz unten

Klarer Fall, ich bin für io_fhem nicht mehr zuständig.

[herrmannj]

Check ! 

Beim ersten Überfliegen bin ich mir auch unsicher ob das Performance Tuning da drin ist. Ansonsten schließe ich mich diesem Satz voll an:

Aber eigentlich ist es mir aktuell auch recht egal. An fronthem tut sich nichts, was zu Änderungen am Treiber führen würde, es stehen keine Problem an, die im Treiber erledigt werden müssten und irgend welche SV2.8 Anpassungen wurden von den SV-Leuten, denen der Treiber nun scheinbar gehört, gemacht.

[HCS]

Check ! 

Trotzdem, nur aus Interesse: haben die sich den Treiber einfach gegriffen oder war das so geplant und abgesprochen?

[herrmannj]

"Gegriffen", ohne da jetzt wirklich was dagegen zu haben.

Loredo liefert ja patches rein, kann also sein das er was dazu sagen kann. Wie allerdings die aktuell in sv enthaltene Version zustande kam habe ich keine Ahnung.

Ich habe gerade nochmal drüber geschaut. (und muss mich da selber wieder reindenken  ). Die performance updates scheinen drin zu sein. Mit einzelnen Anweisungen kommen die Erinnerungen an lange Nächte Stück für Stück zurück 

[dev0]

Klarer Fall, ich bin für io_fhem nicht mehr zuständig.

Das fände ich persönlich sehr schade, wenn Du das für Dich auch so siehst und jetzt nicht nur aus dem Github Context ableitest.
Ich hoffe, dass wir die Situation hier klären können und habe es deshalb auch offen angesprochen.

Meiner Meinung nach solltest Du weiterhin den Hut aufhaben, was die Entwicklung des Treiber angeht und pull requests im git sollten zumindest von Dir abgenickt werden.

[HCS]

Das fände ich persönlich sehr schade, wenn Du das für Dich auch so siehst und jetzt nicht nur aus dem Github Context ableitest.

Naja, da wurden schlicht Fakten geschaffen. Und scheinbar hat man niemanden von der FHEM-Seite mit ins Boot genommen

herrmannj ist der Hutträger auf FHEM-Seite der hier

"Gegriffen", ohne da jetzt wirklich was dagegen zu haben.

dem, was getan wurde, (wohl zumindest nachträglich) zustimmt.

Wie allerdings die aktuell in sv enthaltene Version zustande kam habe ich keine Ahnung.

Ich auch nicht. Irgendwie schon ein seltsamer Vorgang.

... und pull requests im git sollten zumindest von Dir abgenickt werden.

io_fhem ist im Trunk vom SV-Repo und die contributors dort können direkt drauf committen, da gibt es nichts abzunicken, bestenfalls zu beobachten und Einspruch in Form eines Issue einzulegen.

Ich hoffe, Du verstehst, warum ich mich jetzt aktuell gerade nicht mehr so sehr für den Treiber zuständig fühle.
Wenn der Treiber "offiziell" an SV abgegeben wurde, dann ist er abgegeben.
Wenn das nicht das ist, was die FHEM community/developers wollen oder wollten, muss man darüber nachdenken.

Ich sage damit nicht, dass ich mit dem Treiber nichts mehr zu tun haben will, aber alles, was ich aktuell sehe, läuft daruf raus.

Aber wir können den Treiber ja in der Verantwortung von SV lassen, dann können wie einfach Issues mit Wünschen und Problemen auf machen und es wird erledigt. Kling eingentlich auch ganz angenehm. Und wenn das nicht hinhaut, haben wir immer noch die Option, einen eigenen drüber zu bügeln, wie wir es bisher ja auch gemacht haben.

Eins ist aber der Fall. Die offizielle SV2.8 mit dem offiziellen io_fhem läuft bei mir.
Ich muss mir aber mal anschauen, was Neuerungen in SV wie "Auto reconnect for drivers can be enabled in configuration" eigentlich bedeuten und ob das evtl. die gleiche Funktionalität wie der reconnect ist, den ich in io_fhem implementiert habe.

[herrmannj]

herrmannj ist der Hutträger auf FHEM-Seite der hierdem, was getan wurde, (wohl zumindest nachträglich) zustimmt.

Naja, mein Beitrag bestand ja ausschließlich in der Zuarbeit während unser gemeinsamen "Performance-Feldzüge".  . In Bezug aufs copyright bin ich da emotionslos. Btw, der Trick mit den delegates scheint ja auch heute mit dem neuen jquery zu funktionieren  . Von Dir steckt da ganz viel drin, must Du für Dich entscheiden.

io_fhem ist im Trunk vom SV-Repo und die contributors dort können direkt drauf committen, da gibt es nichts abzunicken, bestenfalls zu beobachten und Einspruch in Form eines Issue einzulegen.

Sehe ich auch so. Der driver ist erwachsen und läuft stabil. Was soll da groß passieren.

Ich hoffe, Du verstehst, warum ich mich jetzt aktuell gerade nicht mehr so sehr für den Treiber zuständig fühle.
Wenn der Treiber "offiziell" an SV abgegeben wurde, dann ist er abgegeben.
Wenn das nicht das ist, was die FHEM community/developers wollen oder wollten, muss man darüber nachdenken.

Von meiner Seite erhebe ich keinen Anspruch. Gerade weil ich auch sehr ausgelastet bin renne ich diesem "Hut" nicht hinterher und freue mich wenn jemand die Verantwortung gut übernehmen mag.

Ich sage damit nicht, dass ich mit dem Treiber nichts mehr zu tun haben will, aber alles, was ich aktuell sehe, läuft daruf raus.

Aber wir können den Treiber ja in der Verantwortung von SV lassen, dann können wie einfach Issues mit Wünschen und Problemen auf machen und es wird erledigt. Kling eingentlich auch ganz angenehm. Und wenn das nicht hinhaut, haben wir immer noch die Option, einen eigenen drüber zu bügeln, wie wir es bisher ja auch gemacht haben.

Eins ist aber der Fall. Die offizielle SV2.8 mit dem offiziellen io_fhem läuft bei mir.
Ich muss mir aber mal anschauen, was Neuerungen in SV wie "Auto reconnect for drivers can be enabled in configuration" eigentlich bedeuten und ob das evtl. die gleiche Funktionalität wie der reconnect ist, den ich in io_fhem implementiert habe.

Die Hauptarbeit kommt von Dir. Nach meiner Meinung wäre diese Entscheidung bei Dir.

Es werden auch wieder Zeiten kommen wo neue Arbeit entsteht  Es wäre mir eine Ehre dann mit Dir teamen zu dürfen. 

btw, erinnere ich mich richtig das Du dort bist wo "Küchenschrank" zu Sprachtraining gehört ? Oder bring ich da was durcheinander..

vg
joerg

[dev0]

herrmannj ist der Hutträger auf FHEM-Seite der hier

Dann habe ich das falsch in Erinnerung. Ich dachte Du hättest den Treiber geschrieben.

Ich hoffe, Du verstehst, warum ich mich jetzt aktuell gerade nicht mehr so sehr für den Treiber zuständig fühle.
Wenn der Treiber "offiziell" an SV abgegeben wurde, dann ist er abgegeben.

Ich verstehe, dass du aktuell "not amused" bist, wäre ich auch nicht.

io_fhem ist im Trunk vom SV-Repo und die contributors dort können direkt drauf committen, da gibt es nichts abzunicken, bestenfalls zu beobachten und Einspruch in Form eines Issue einzulegen.

Wenn den sv Maintainern klar ist, wer den Hut auf hat, dann könnte das auch anders laufen: man wird gefragt oder wartet bis in den Kommentaren ein OK kommt. Ich denke nicht das den sv Leuten klar ist, dass der Treiber nicht von @rammann oder @jpawlowski stammt.
Edit: Oder die commits werden vorher hier im Forum abgesprochen, auch darauf könnte man sich doch verständigen.

Der driver ist erwachsen und läuft stabil. Was soll da groß passieren.

Direkt passieren nix, aber hier kam die Idee auf, den Treiber anzupassen. Ich habe zu wenig Ahnung von js und dem Treiber, um beurteilen zu können ob es vielleicht doch Wechselwirkungen mit anderen Widgets gibt. An der Stelle würde ich mir schon jemanden mit einem Hut wünschen, der nochmals drüber schaut und es abnickt. Vielleicht könnte man das ja auch viel geschickter ohne solch eine Änderung umsetzen. Die sv Maintainer kennen sich mit FHEM nicht aus und können das nicht beurteilen.

[HCS]

Dann habe ich das falsch in Erinnerung. Ich dachte Du hättest den Treiber geschrieben.

Doch schon, habe ich, aber im Rahmen des fronthem Projekts. Der Treiber ist jetzt auch nicht mein persönlicher Besitz, auch wenn ich ihn geschrieben habe.
Ohne fronthem ist der Treiber genau nichts und ich habe das übernommen, um herrmannj zuzuarbeiten und weil ich einige Dinge gerne drin haben wollte (AddOn-Treiber-Anbindung, reconnect) und weil Performance gesucht werden musste. Der Treiber war an den Erfordernissen und Vorgaben von fronthem orientiert und da hat herrmannj nun mal den Hut mit Pattex fest aufgesetzt. Ich sehe mich auch nicht als denjenigen, der alleine zu bestimmen hat, was mit dem Treiber geschieht. Er gehörte bisher der FHEM-Community. Ob diese ihn an SV abgibt und nur noch eine Beraterrolle mit etwas Vetorecht einnehmen will, ist auch nicht meine persönliche Entscheidung.

Versteht mich bitte richtig - ich bin etwas überrascht von der Situation, verstehe sie auch noch nicht so richtig und habe keinerlei Anspruchsdenken, was aus "meinem" Treiber werden darf. Wenn die Lösung "SV hat die Treiber-Hoheit" für das Gesamtprojekt sinnvoll ist, dann ist das für mich auch völlig OK.

Wenn den sv Maintainern klar ist, wer den Hut auf hat, dann könnte das auch anders laufen: man wird gefragt oder wartet bis in den Kommentaren ein OK kommt. Ich denke nicht das den sv Leuten klar ist, dass der Treiber nicht von @rammann oder @jpawlowski stammt.
Direkt passieren nix, aber hier kam die Idee auf, den Treiber anzupassen. Ich habe zu wenig Ahnung von js und dem Treiber, um beurteilen zu können ob es vielleicht doch Wechselwirkungen mit anderen Widgets gibt. An der Stelle würde ich mir schon jemanden mit einem Hut wünschen, der nochmals drüber schaut und es abnickt. Vielleicht könnte man das ja auch viel geschickter ohne solch eine Änderung umsetzen. Die sv Maintainer kennen sich mit FHEM nicht aus und können das nicht beurteilen.

Ich muss mir das Ganze mal in Ruhe und wenn ich Zeit habe anschauen, was da eigentlich gemacht wurde und was der verlinkte Änderungswunsch z.B. bedeutet und überhaupt.
Wir sollten auch achtgeben, dass wir das ganze Thema jetzt nicht zum Super-Drama hochdiskutieren.

[dev0]

Wir sollten auch achtgeben, dass wir das ganze Thema jetzt nicht zum Super-Drama hochdiskutieren.

ACK!!!

Ich sehe mich auch nicht als denjenigen, der alleine zu bestimmen hat, was mit dem Treiber geschieht.

Schön, dass Du das halbwegs relaxed siehst. Ich fände es gut, wenn wir eine "Instanz" oder auch nur einen Thread hätten, in dem Änderungen vorgestellt/diskutiert werden könnten. Dadurch könnten wir es vll vermeiden, dass grobe Schnitzer passieren. Ist mir auch erst jetzt gerade einfallen, wo wir drüber reden...

Die aktuell vorgeschlagenen Treiber-Änderungen brauchst Du Dir noch nicht konkret anzusehen. Ich bin mit der Lösung so noch nicht d'ac­cord bzw. hatte ich auch noch keine Zeit mich tiefer einzudenken.

[herrmannj]

Ja, volle Zustimmung. Immer schön Kirche im Dorf lassen.

So als Instanz (wie auch immer) unterstütze ich. Ich denke zwar dass das Schadenspotential gering ist weil die Funktion ja klar abgegrenzt ist. Allerdings stimmts, zu schnell wird "irgendwas" da rein gepatched was auf andere Art schon da ist. Hinterher bekommt man das schwer zurückgedreht.

so beim Nachdenken - schon besser das zu moderieren.

vg
joerg

[smai]

Hallo zusammen

Als aktueller Maintainer der smartVISU habe ich diesen Thread erst jetzt entdeckt.

Zuerst will ich mich entschuldigen, dass ich den Treiber aus eurer Sicht "gegriffen" habe.

Ich möchte betonen, dass jpawlowski nicht Teil des smartVISU Teams ist. Viel mehr bin ich davon ausgegangen, dass er Teil eures Teams ist. Er hat einen Pull Request mit dem Treiber gestellt, den ich gemerged habe. Bis vor 2 Minuten war mir nicht bewusst, dass der Treiber gar nicht von ihm ist.

Deshalb nochmal ein grosses SORRY.

Neben meiner Entschuldigung möchte ich an dieser Stelle aber auch eine kleine Bitte los werden. Ich hatte mich nämlich sehr über den Pull Request gefreut, weil damit endlich was von euch in die smartVISU integriert wurde.
Ihr macht viele tolle Korrekturen und Widgets, aber pflegt das alles in eigenen (nicht geforkten) Repositories, so dass der Rest der Welt gar nie davon erfährt.
Ein Grundgedanke hinter Open Source wäre ja, dass man eigene Anpassungen und Ideen auch wieder einbringt.

Deshalb seid Ihr herzlich eingeladen, Fehler und Ideen als Issue zu melden, Pull Requests mit euren Anpassungen zu stellen oder im offiziellen smartVISU Forum und im Gitter Chat mitzudiskutieren.

Ich würde mich freuen, von euch zu hören.

Grüsse
Stefan

[dev0]

Deshalb nochmal ein grosses SORRY.

Ich denke nicht, dass ein Maintainer eines Open Source Projekts die Quellen aller Pull Requests checken muss/sollte/kann woher der Code stammt. Alles ist gut Es ist aber sehr nett, dass Du Dich dazu geäußert hast!

Ihr macht viele tolle Korrekturen und Widgets, aber pflegt das alles in eigenen (nicht geforkten) Repositories, so dass der Rest der Welt gar nie davon erfährt.

Ich kann nur von mir sprechen und ich hatte vor einiger Zeit den Eindruck, dass Martin nicht sehr interessiert an Pull Requests ist/war. Da ich zZ. aber auch nichts für SV entwickle, kann ich nur anbieten, dass Ihr gerne alles von https://github.com/ddtlabs/smartvisu-widgets nutzen könnt. Laut einem Beitrag hier im Forum funktioniert aber zB. das Sonos Widget nicht mehr ordentlich mit der aktuellen 2.9er...