Qualität von FHEM

[Amenophis86]

Und im Anfängerforum hat so ein FHEM Bashing schon mal gar nichts verloren. Der Thread ist also in mehrfacher Hinsicht sinnlos und fehl am Platz. Bevor das hier noch zu einer großen Sache wird, sollte er geschlossen werden.

Solange die Diskussion Sachlich verläuft gibt es keinen Grund den Thread zu schließen. Das er besser in ein anderes Board (Sonstiges zB) gepasst hätte mag stimmen und darf auch gerne dahin verschoben werden. Ansonsten hole ich mir Popcorn und bin gespannt, wie es weiter geht

[marvin78]

Bevor ein so komplexes Thema im Anfängerforum diskutiert wird, schließt man es besser. Wenn es dem TE wirklich um

Ich will gerne FHEM weiter voran bringen; dazu sollten wir dann eine Art Release Prozess definieren.

geht, gehört das hier schlicht nicht hin.

[krikan]

Finde ich nicht bzw. habe ich etwas verpasst:

Welcher reproduzierbare Fehler in FHEM bzw. in einem Modul liegt/lag(?) genau vor, der zur Aussage des TE führte? Mir ist keiner bekannt.

Liegt wirklich ein Fehler von FHEM oder ein anderer Fehler externer Einflußfaktoren vor?

[CoolTux]

Ich versuche ja schon vom TE Lognachweise zu bekommen. Aber irgendwie mag er wohl nicht.

[Beta-User]

Warum nicht im Anfängerforum? M.E. macht es durchaus Sinn, dass sich auch und gerade Anfänger über die dauerhafte Plege ihrer Landschaft Gedanken machen.

Dass FHEM2FHEM eine gute Variante sein könnte, um das Thema der Einbindung echter Hardware zu testen, darauf wäre ich alleine nicht gekommen - wobei m.E. dabei ein echtes Klonen nicht geht, da sonst alle Timer etc. ja doppelt wären.

Interessant dürfte allerdings sein, was denn jetzt tatsächlich der Auslöser für das ursprüngliche Problem war. Zwar nutze ich PRESENCE nicht, mir wäre aber auch nicht bewußt, dass es da irgendwelche größeren Probleme gegeben hätte. Könnte es sein, dass es eine unglückliche Programmierung durch den TE war, die das eigentliche Problem verursacht hat ?

Wenn es das wäre: Solche Probleme könnte man durch eine Verbesserung der FHEM-seitigen Codebasis auch nicht verhindern.

Ansonsten: Es wäre mir neu, dass es eine Art Qualitätssicherung gäbe, die ALLE Module umfasst, die mit einer bestimmten Version ausgeliefert werden. War und ist es nicht so, dass jeder irgend ein beliebiges Modul einchecken darf, solange es eine englische Commandref und die Zusage für 3 Monate Support gibt?

Im Übrigen: der Kernbestand der FHEM-Module und insbesondere fhem.pl sind nach meinem Empfinden unglaublich stabil, für eine Generalkritik an FHEM besteht keinerlei Anlaß!

Just my2ct.

Gruß, Beta-User

[rudolfkoenig]

dazu sollten wir dann eine Art Release Prozess definieren.

Das bedeutet parallel zwei Versionen zu pflegen. Ich bin unsicher, ob die meisten Entwickler dazu die Energie haben, ich sicher nicht. Dass eine "developer" Version sinnvoll getestet wird, halte ich auch fuer ein Geruecht, siehe die Geschichte bei Aktivierung von fwcsrf mit 5.8.

Ich finde es klasse, wenn Leute haeufig ein update machen, weil sie damit aktiv beim Testen helfen. Wer auf die Dienste von FHEM angewiesen ist, der sollte zum Testen Zeit einplanen, und vorher ein Backup des Systems erstellen. Bei "ernstzunehmenden" Firmen ist das vor einem update selbstverstaendlich, auch bei bezahlten Produkten mit Supportvertrag, wo man erwarten kann, dass der Hersteller ein Release getestet hat.

FHEM ist meiner Ansicht komplizierter zu testen als die meisten Softwareprodukte, weil es mit so vielen Geraeten interagiert, und sehr konfigurabel ist. Um ein Release in herkoemmlichen Sinne anzubieten muesste man FHEM stark einschraenken.

Gegen einem automatisierten Test-Suite haette ich nichts einzuwenden, das wuerde aber trotzdem nur eine sehr begrenzte Menge an Problemen abfangen koennen. Deswegen bin ich unsicher, ob der Aufwand dafuer sich lohnt.

[Amenophis86]

Und schon sind wir in einer sinnvollen Diskussion angekommen und bei dem Grund, warum der Thread nicht direkt geschlossen werden muss, nur, weil ein einzelner User diesen (ich sage mal) "nicht korrekt" angefangen hat.

[marvin78]

Und schon sind wir in einer sinnvollen Diskussion angekommen und bei dem Grund, warum der Thread nicht direkt geschlossen werden muss, nur, weil ein einzelner User diesen (ich sage mal) "nicht korrekt" angefangen hat.

Du hast meinen Beitrag nicht gelesen oder nicht verstanden. Der Thread gehört mit der Intention, die da hinter steckt, nicht in "AnfägerFRAGEN". Es ist keine solche und Anfänger können hier wenig beitragen. Aber was soll's...


FHEM ist in seinem update-Prozess unkompliziert und es ist gut so wie es ist, wenn man die übliche Klientel berücksichtigt. Es gibt keinen Grund, den Prozess komplizierter zu machen (und damit meine ich komplizierter für Entwickler und Betreiber). Man sollte nicht den Anfängern das Leben so leicht wie möglich machen, wenn es bedeutet, dass man die Betreiber und Entwickler damit belastet. Es ist wesentlich einfacher und praktikabler, wenn jeder einzelne einfach das tut, was nötig ist.


Wenn es eine sogenannte "stable" Version von FHEM geben soll, dann muss das ein gesondertes Projekt sein, welches von einer anderen Gruppe von Leuten betrieben wird. Da sehe ich dann wieder viele neue Probleme.

[A.Harrenberg]

Hi,

Das bedeutet parallel zwei Versionen zu pflegen. Ich bin unsicher, ob die meisten Entwickler dazu die Energie haben, ich sicher nicht. Dass eine "developer" Version sinnvoll getestet wird, halte ich auch fuer ein Geruecht, siehe die Geschichte bei Aktivierung von fwcsrf mit 5.8.

ich hätte mir machmal auch gewünscht das einige Sachen die ich so gemacht habe erst mal in einem kleineren Kreis getesten worden wären und erst danach verzögert in das offizielle Update gelangen...
Aber ich gebe Dir Recht, das würde einen parallelen Zweig voraussetzen den es dann auch zu pflegen gilt und der auch nur Sinn machen würde wenn dort Nutzer aller Module vertreten sind.

Mir würde da nur eine zeitliche Abhängigheit einfallen. "Tester" erhalten jedes Update sofort wie bisher, "normale User" erhalten Updates z.B. erst eine Woche später, solange der Autor diese Version des Moduls in der Zeit nicht als fehlerhaft deklariert.
Problem dabie ist aber zu bewerten ob ein Bugfix wirklich installiert werden kann oder er weitere/andere Probleme auslöst da vielleicht mit etwas zu heißer Nadel an der Lösung des Problems gearbeitet wurde.

Das ganze würde aber wohl hinreichend kompliziert werden... Letzendlich wäre es genauso als würde der Modulautor ein "Roll-Back" als Update veröffentlichen bis das Problem erkannt und behoben ist. Meist ist aber genauso schnell auch der Bugfix fertig...

Gruß,
Andreas.

[the ratman]

... solange der Autor diese Version des Moduls in der Zeit nicht als fehlerhaft deklariert.

da bräuchte man aber viel leute.
ein tester müsste dann ja quasi jede hardware mit jedem system und allen modulen haben. ich denk da nur an z.b. mein problem mit der unverträglichkeit des lgtv-moduls mit dem dlna-modul. da kommts schon drauf an, ob der tv in standby oder off geht. wer testet auf sowas?

rennt doch super, wie es ist. meist macht ein update eh keine probleme und ansonsten kopiert man halt aus dem backup-ordner zurück und schreit hier laut um hilfe. am nächsten tag geht dann meistens alles.