https://forum.fhem.de/index.php/topic,79858.0.html
Wie kann man hier am besten verfahren? Martin wurde wohl bereits informiert, dennoch tut sich nichts trotz einer Kleinigkeit.
Welche möglichkeiten, ausser Patch bei Martin einreichen, haben die anderen Developer um die User zu unterstützen?
Grüße
Mir faellt ein:
- Immer wieder auf das Problem hinweisen und warten.
- Alternativmodul schreiben.
Selbst sein Modul zu Patchen ist keine Option.
Danke Dir Rudi
Zitat von: rudolfkoenig am 24 November 2017, 10:11:07
Selbst sein Modul zu Patchen ist keine Option.
Du sprichst hier von Patchen und via SVN verteilen? Gegen Patchen und via Thread verteilen ist in Ordnung? Siehe: https://forum.fhem.de/index.php/topic,79858.msg720176.html#msg720176
Zitat von: Hauswart am 24 November 2017, 10:25:05
Du sprichst hier von Patchen und via SVN verteilen? Gegen Patchen und via Thread verteilen ist in Ordnung? Siehe: https://forum.fhem.de/index.php/topic,79858.msg720176.html#msg720176
Meine Meinung. Ich finde es ok. Das Problem ist das ich finde das das (man eine Menge das) File nach Bereinigung des Problemes wieder entfernt werden sollte.
Hi,
erst einmal vorweg: Ich bin ein Verfechter des "strengen Code-Ownership". D.h. für jedes Stückchen Coding gibt es einen "Oberboss", der im Endeffekt das Sagen hat.
Aaaaber:
Es kann gut sein, dass derjenige mal krank ist, vom Auto überfahren wird oder ohne Handy im australischen Outback wandert. In dem Fall finde ich es auch nicht ganz richtig, wenn man das ganze Modul neu schreiben müsste. Da sollten wir schon, zumindest bei Sachen, die ganz klar ein Fehler sind (wie hier), auch in "fremdem" Coding einen Fix einbauen können. Es ist mir auch klar, dass jemand anders nicht immer wissen kann, was eigentlich die Intention des betreffenden Codings war, aber ein erfahrener Entwickler wird trotzdem in den meisten Fallen etwas machen können.
Natürlich muss darüber der eigentliche Maintainer immer so gut es geht informiert werden und das sollte auch nicht leichtfertig gemacht werden. Andererseits ist aber auch blöd, wenn man bei einem so wichtigen Modul wie 10_CUL_HM.pm irgendwelche Umgehungslösungen braucht, damit es überhaupt läuft.
Längerfristig könnte ich mir vorstellen, dass jeder Maintainer einen "Vize-Maintainer" ernennt.
Gruß,
Thorsten
Vorschlag:
Jemand (namentlich) übernimmt die Prozess und macht:
- Info am Martin, PM und Mail
- letzte funktionierende version im SVN wieder herstellen.
- Martin macht das dann heil sobald er die Chance dazu hat.
Wir haben alle ein rl !
Da ich im Homematic-Thread die Lösung ja schon identifiziert habe, kann ich das gerne übernehmen:
- martin anschreiben
- funktionierendes Modul mit bugfix des aktuellen Problems als interims-Lösung einchecken, bis martin das selbst korrigiert hat
perfekt. Danke.
Zitat von: betateilchen am 24 November 2017, 11:36:29
Da ich im Thread die Lösung ja schon identifiziert habe, kann ich das gerne übernehmen:
Ich bin auch dafür.
Gruß,
Thorsten
kann bitte jemand den dortigen Thread https://forum.fhem.de/index.php/topic,79858.0.html schließen?
Da wird inzwischen über Dinge diskutiert, die mit dem Bug nix mehr zu tun haben...
Zitat von: herrmannj am 24 November 2017, 11:31:14
Vorschlag:
Jemand (namentlich) übernimmt die Prozess und macht:
- Info am Martin, PM und Mail
- letzte funktionierende version im SVN wieder herstellen.
- Martin macht das dann heil sobald er die Chance dazu hat.
Wir haben alle ein rl !
In diesem Fall wäre ein Roolback etwas suboptimal. Laut dem Comment waren einige wichtige Bugfixes dabei. Daher würde hier wohl ein fix, zu mal es nur um ein Wort geht, besser angebracht.
Ich kann mich an Martin per PN wenden (Mail ist aktuell mir nicht bekannt, kann aber mal schauen) und einen fix im SVN bereit stellen.
Meinungen dazu?Sorry hat Udo seinen Post übersehen.
Zitat von: betateilchen am 24 November 2017, 11:39:44
kann bitte jemand den dortigen Thread https://forum.fhem.de/index.php/topic,79858.0.html schließen?
Da wird inzwischen über Dinge diskutiert, die mit dem Bug nix mehr zu tun haben...
Vielleicht erstmal ne kleine Mahnung in Worte einbringen das man sich doch bitte am Thema halten soll.
Zitat von: betateilchen am 24 November 2017, 11:39:44
kann bitte jemand den dortigen Thread https://forum.fhem.de/index.php/topic,79858.0.html schließen?
Da wird inzwischen über Dinge diskutiert, die mit dem Bug nix mehr zu tun haben...
done
Danke.
Der bugfix ist eingecheckt. Falls Rudi Lust und Zeit findet, könnte er vielleicht heute nochmal ein update generieren, damit den Anwendern schnell geholfen werden kann.
Zitat von: betateilchen am 24 November 2017, 11:36:29
- martin anschreiben
- funktionierendes Modul mit bugfix des aktuellen Problems als interims-Lösung einchecken, bis martin das selbst korrigiert hat
Ist das nun die offizielle Herangehensweise?
Wir reden hier über eine Ausnahmesituation.
Die beiden Punkte sind inzwischen beide erledigt.
ZitatIst das nun die offizielle Herangehensweise?
Ich würde nicht versuchen das zu generalisieren, es kommt einfach auf den Einzelfall an. Aber _ich_ würde mich darüber freuen, wenn Kollegen eingreifen, wenn ein Problem auftritt und ich nicht "erreichbar" bin.
Zitat von: dev0 am 24 November 2017, 12:04:14
Ich würde nicht versuchen das zu generalisieren, es kommt einfach auf den Einzelfall an. Aber _ich_ würde mich darüber freuen, wenn Kollegen eingreifen, wenn ich ein Problem auftritt und ich nicht "erreichbar" bin.
dito
ZitatEs kann gut sein, dass derjenige mal krank ist, vom Auto überfahren wird oder ohne Handy im australischen Outback wandert.
Klar, und sowas haben wir laufend. Im ersten und im letzten Fall apelliere ich an die Geduld der Benutzer.
Fuer den zweiten Fall gibt es den Regel: Autor anschreiben, und falls nach 3 Wochen keine Antowrt, dann ist das Modul verweist, ich verwalte es kommissarisch solange, bis jemand "hier" schreit, danach ist dieser der neue Maintainer. Wer vor hat laenger als 3 Wochen krank zu sein, oder im australischen Outback rumzuwandern, der sollte einen Stellvertreter ernennen oder einfach darauf Hinweisen, damit wir geduldiger sind.
ZitatDer bugfix ist eingecheckt.
Ich hoffe das bleibt eine einmalige Ausnahme. Sonst sehe ich die Gefahr von Leuten, die es gut meinen, aber den Code oder die Absichten des Autors nicht ganz verstehen, und durch die Aenderung nur die Arbeit des Autors erschweren.
ZitatFalls Rudi Lust und Zeit findet, könnte er vielleicht heute nochmal ein update generieren, damit den Anwendern schnell geholfen werden kann.
Das habe ich gemacht.
Zum Problem: ich verstehe die Aufregung noch nicht: soweit ich es sehe, geht es um eine Warnung, und nicht mehr.
Zitat von: rudolfkoenig am 24 November 2017, 13:43:49
Zum Problem: ich verstehe die Aufregung noch nicht: soweit ich es sehe, geht es um eine Warnung, und nicht mehr.
Nein, es geht nicht um eine Warnung, es geht um einen harten Abbruch, der das Laden des Moduls verhindert. Damit funktionieren keinerlei Homematic Komponenten mehr.
Zitat von: rudolfkoenig am 24 November 2017, 13:43:49
Ich hoffe das bleibt eine einmalige Ausnahme.
Keine Sorge, in der Zeit, die ich jetzt mit FHEM zu tun habe, habe ich sowas zum zweiten Mal gemacht. Und ich mache sowas nicht leichtfertig, sondern nur, wenn ich wirklich genau verstanden habe, was das Problem ist und ich auch genau weiß, dass die Änderung das tut, was beabsichtigt ist. Im vorliegenden Fall eine Änderung im Verhalten von perl, die auf perldoc genau beschrieben ist - inklusive der neuen Vorgehensweise als Lösung.
Aber ich wollte nicht drei Wochen warten, da die Anzahl der Problemmeldungen immer größer wurde ;)
Zitat von: betateilchen am 24 November 2017, 13:49:22
Nein, es geht nicht um eine Warnung, es geht um einen harten Abbruch, der das Laden des Moduls verhindert. Damit funktionieren keinerlei Homematic Komponenten mehr.
Das hängt anscheinend aber von der Perl-Version ab. Bei manchen ist es nur eine Warnung, bei anderen knallt es komplett.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 24 November 2017, 13:51:21
Das hängt anscheinend aber von der Perl-Version ab. Bei manchen ist es nur eine Warnung, bei anderen knallt es komplett.
Das hatte ich ja bereits an anderer Stelle (https://forum.fhem.de/index.php/topic,79858.msg719329.html#msg719329) genau so beschrieben ;)
Zitat von: betateilchen am 24 November 2017, 13:59:58
Das hatte ich ja bereits an anderer Stelle (https://forum.fhem.de/index.php/topic,79858.msg719329.html#msg719329) genau so beschrieben ;)
Das ist mir durchaus bekannt, ich war nur zu faul, es herauszusuchen.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 24 November 2017, 13:51:21
Das hängt anscheinend aber von der Perl-Version ab. Bei manchen ist es nur eine Warnung, bei anderen knallt es komplett.
Gruß,
Thorsten
Bei aktuellen perl Versionen knallt es.
Das bedeutet(e) konkret:
wenn ein user mit aktueller perl version ein von uns ausdrücklich empfohlenes, regelmaßiges fhem update macht funktionieren danach HM Komponenten nicht mehr.
https://perldoc.perl.org/functions/defined.html
ZitatUse of defined on aggregates (hashes and arrays) is no longer supported. It used to report whether memory for that aggregate had ever been allocated. You should instead use a simple test for size:
Das stellt deutlich mehr als nur eine Warnung dar.
edit: soweit ich sehe lässt sich "aktuell" auf >= 5.12 legen. Wenn das stimmt wäre das 2010
Zitat von: herrmannj am 24 November 2017, 14:16:01ein von uns ausdrücklich empfohlenes, regelmaßiges fhem update
Echt? Wo wird das empfohlen? Ich mache auf meinem Produktivsystem etwa einmal im Jahr (höchstens) ein FHEM update. Das wäre auch meine Empfehlung bei einem ansonsten gut laufenden System.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 24 November 2017, 15:01:59
Echt? Wo wird das empfohlen? Ich mache auf meinem Produktivsystem etwa einmal im Jahr (höchstens) ein FHEM update. Das wäre auch meine Empfehlung bei einem ansonsten gut laufenden System.
Gruß,
Thorsten
Naja, jeder der im forum um Hilfe bittet der wird recht zügig darauf angesprochen: System aktuell, update gemacht ?
Macht ja auch Sinn. Ich würde selbst mein Produktivsystem nicht 365 Tage alt lassen. Einmal im Monat kommt ein Update. Dafür wird vorher im Forum gestöbert und auf einem Testsystem die groben Dinge durchlaufen welche man testen kann.
Geht jetzt hier die gleiche sinnlose Diskussion los wie im ursprünglichen Problem-Thread?
Zitat von: herrmannj am 24 November 2017, 14:16:01
edit: soweit ich sehe lässt sich "aktuell" auf >= 5.12 legen. Wenn das stimmt wäre das 2010
Ich habe hier eine produktive FHEM Installation mit perl 5.20.2 die völlig problemlos läuft und bei der es NICHT knallt.
Zitat von: herrmannj am 24 November 2017, 15:40:37
Naja, jeder der im forum um Hilfe bittet der wird recht zügig darauf angesprochen: System aktuell, update gemacht ?
Ok, wenn was nicht klappt, dann sollte man natürlich erst einmal sicher stellen, dass man nicht auf einen alten Fehler gerannt ist. Das ist klar.
Zitat von: CoolTux am 24 November 2017, 15:44:42
Macht ja auch Sinn. Ich würde selbst mein Produktivsystem nicht 365 Tage alt lassen. Einmal im Monat kommt ein Update. Dafür wird vorher im Forum gestöbert und auf einem Testsystem die groben Dinge durchlaufen welche man testen kann.
Ich mache das eher umgekehrt. So lange alles stabil läuft lasse ich es so, wie es ist. Im Forum gestöbert wird eh ständig und wenn mal was wichtiges hochkommt (z.B. sicherheitsrelevant), dann kommt ein update.
Zitat von: betateilchen am 24 November 2017, 15:56:58
Geht jetzt hier die gleiche sinnlose Diskussion los wie im ursprünglichen Problem-Thread?
Wieso sinnlos? Off-topic vielleicht, aber meiner Meinung nach nicht sinnlos.
Zitat von: betateilchen am 24 November 2017, 15:58:38
Ich habe hier eine produktive FHEM Installation mit perl 5.20.2 die völlig problemlos läuft und bei der es NICHT knallt.
Hier zwar nicht produktiv, aber Perl v5.22.1 und es knallt. 10_CUL_HM.pm wird überhaupt nicht geladen. Wenn ich mir das Coding aber scharf anschaue, kann ich mir vorstellen, dass das vom "expert" Attribut abhängt. Wenn man niemals irgendwas mit einem gesetzten Bit 3 (etwa 8, 12, 251) hat, dann knallt es wohl eh nicht.
Gruß,
Thorsten
Zitat von: Thorsten Pferdekaemper am 24 November 2017, 21:09:53
Hier zwar nicht produktiv, aber Perl v5.22.1 und es knallt. 10_CUL_HM.pm wird überhaupt nicht geladen. Wenn ich mir das Coding aber scharf anschaue, kann ich mir vorstellen, dass das vom "expert" Attribut abhängt.
Das wäre aber ein anderes Problem als das, worum es im aktuellen Fall ging. Die betroffene und gestern angepasste Stelle hatte was mit templates zu tun, nicht mit Attributen.
Zitat von: betateilchen am 25 November 2017, 11:06:24
Das wäre aber ein anderes Problem als das, worum es im aktuellen Fall ging. Die betroffene und gestern angepasste Stelle hatte was mit templates zu tun, nicht mit Attributen.
Beides, würde ich sagen. Wenn Bit 3 des Attributs expert gesetzt ist, dann passiert irgendwas mit Templates, soweit ich das verstehe.
Gruß,
Thorsten
ok, dann habe ich Deinen vorletzten Beitrag falsch interpretiert. Das Bit3 selbst ist nicht das Problem, sondern das, was passiert, wenn Bit3 gesetzt ist ;) Dann passt ja alles wieder.
Das gestern eingecheckte Modul sollte sich aber auch bei Dir laden lassen, selbst wenn Bit3 gesetzt ist.
Zitat von: betateilchen am 25 November 2017, 12:07:04Das gestern eingecheckte Modul sollte sich aber auch bei Dir laden lassen, selbst wenn Bit3 gesetzt ist.
Ja, das funktioniert.
...zumindest an der Stelle. Dummerweise erzeugen die BlockingCalls unter Windows Probleme, aber das interessiert nicht wirklich sooo sehr, da das für mich nur ein Spielsystem ist.
Gruß,
Thorsten
Martin hat heute eine neue Modulversion eingecheckt, die neben der gestrigen ad-hoc Lösung auch noch weitere Änderungen enthält.
Insofern dürfte das Thema nun auch "offiziell" erledigt sein.