Einstieg in FHEM-Entwicklung

Begonnen von pldemon, 31 März 2021, 09:54:40

Vorheriges Thema - Nächstes Thema

pldemon

Hallo,

versuche zwar nicht aktiv in die Entwicklung von FHEM einzusteigen, bin aber im Moment dabei meine Hausautomatisierung weiter voranzubringen und programmiere deshalb etliche Sachen. Dabei bin ich diversen Fehlern in FHEMs Modulen begegnet, die ich natürlich gleich korrigiere und  gerne auch an die Community übermitteln will. Im Zuge der Mitarbeit ist mir aber aufgefallen, dass die Rampe bei FHEM teils hoch (und frustrierend) ist im Vergleich mit anderen Projekten.

Laut der Doku sollen Patches direkt im Forum eingereicht werden, was nicht unbedingt schlecht ist und beispielsweise der Vorgehensweise im Linux-Kernel entspricht, wo Patches in der LKML öffentlich gepostet werden. Dass man dazu hier SVN installieren muss, ist zwar ungewöhnlich, aber nicht wirklich schlimm.

Meine Erfahrung zeigte aber, dass die Patches im Forum nicht selten ignoriert/nicht beachtet werden. Das führt dann dazu, dass bereits gefixte Fehler sich teils noch Monate im Code befinden. Das zeigte beispielsweise eine kürzliche Diskussion im Wetterforum zu einem Problem, das ich eigentlich schon vor über einem Jahr korrigiert und den Patch an den Autor geschickt habe. Dasselbe gilt für ein Problem in Text2Speach – auch hier wurde der beschriebene Fehler schon korrigiert und der Patch an den Autor gemeldet.

Leider muss ich sagen, dass die im Wiki beschriebene Vorgehensweise, wie man die Patches an FHEM übermittelt, bisher nur von einem Autor akzeptiert wurde. Die Anderen haben die Fehlerkorrekturen schlicht nicht beachtet. Wollte ich die Korrekturen voranbringen, musste ich als Projektfremder ziemlich viel Zeit für die Aufnahme investieren. Das ist natürlich bei Fehlern, die teils bis zum Absturz von FHEM führen, nicht wirklich schön.

Wurden die Korrekturen irgendwann doch beachtet, wurden sie nicht akzeptiert. Grund dafür war, dass sie Entwickler separate Development-Stände in Git hatten und einen Pull-Request wünschten (weil es für sie einfacher war). Wollte man sie also mit Patches unterstützen, musste man sich dieses Mal ihre privaten Repositorien aus GitHub holen, einen neuen Patch dagegen schreiben und diesen dann per Pull-Request senden. Spätestens hier bin ich bei meinen ersten Patch-Submissions vor einem Jahr ausgestiegen. Denn, da hatte ich für die Übermittlung einer Einzeiler-Korrektur bereits mehr Zeit aufgewandt, als für die Implementierung und Submission diverser neuer Funktionen in Tasmota (kein Scherz!).

Ich kann durchaus verstehen, dass die Entwickler wenig Zeit haben und sich die Arbeit ersparen wollen, aber... Ihr solltet beachten, dass auch die Unterstützer nicht über unendlich viel Ressourcen verfügen. Denn nicht selten, sind es Leute, die selbst in anderen Projekten aktiv sind und die ebenfalls über mangelnde Zeit klagen. Optimalerweise haben sie sich an die von euch beschriebene Vorgehensweise für die Übermittlung von Patches gehalten und wenn sie nicht funktioniert, dann gehen sie weiter. Das ist mir vor einem Jahr passiert, was dazu führte, dass die Korrekturen nicht in die Module eingebunden wurden und die Anwender immer noch über die Fehler stolpern.

Meine Erfahrung zeigte, dass man als Projekthelfer recht viel Zeit und Energie bei FHEM für die Übermittlung von Korrekturen aufbringen muss. Ich will euch dabei natürlich keine Ratschläge und/oder Belehrungen erteilen. Ich wollte nur auf meine Beobachtungen als externe Hilfskraft hinweisen, die ihr vielleicht intern nicht sieht.

Gruß,
Mirko

Beta-User

Hallo zurück.

Vorab: bzgl. der Nutzung von git statt svn gibt es immer mal wieder Anfragen, nach meiner - eventuell unvollständigen - Kenntnis ist https://forum.fhem.de/index.php/topic,20395.msg264494.html#msg264494 ein guter Einstieg, um den aktuellen Stand zu verstehen.

Zitat von: pldemon am 31 März 2021, 09:54:40Dass man dazu hier SVN installieren muss, ist zwar ungewöhnlich, aber nicht wirklich schlimm.
patches sollten sich auch mit einem "einfachen" "diff -u" erstellen lassen, eine svn-Installation sollte eigentlich nicht erforderlich sein.

ZitatMeine Erfahrung zeigte aber, dass die Patches im Forum nicht selten ignoriert/nicht beachtet werden. [...]
Das ist natürlich bedauerlich und sollte nicht die Regel sein.

Aus meiner persönlichen Warte als eher Ungeübter mit diesen ganzen Tools:
Vermutlich ist die Wahl, alles über patches zu machen nicht mehr unbedingt "modern" und wird daher von manchen abgelehnt bis (nahezu) boykottiert. Aber es ist eine relativ einfache und transparente Methode, die keine vertieften Kenntnisse z.B. der in github hinterlegten Workflows erfordert, und kommt mir als "Gelegenheitsmaintainer" daher eher entgegen. Im Ergebnis ist es (wenn man die erweiterten Features von git (? z.B. feature requests etc.) nicht auch nutzt): "Geschmackssache"...
Dass die Welt so oder so bunt ist, wird sich auch kaum vermeiden lassen, dann wieder Maintainer andere bevorzugen vollständige Modulversionen als Anhang via Forum, und bei der Diskussion über "Einzeiler" stellt sich dann ggf. auch die Frage, ob jemand die Rolle als Maintainer überhaupt noch annimmt. Das hat dann gar nichts mehr mit der Wahl der Mittel zu tun....

Na ja, wie dem auch sei: Danke von meiner Seite über die Rückmeldung!

PS: Das obige ist kein Vorum für irgendein Toolset. Letztlich ist es mir persönlich gleichgültig, welches eben dann zu benutzen ist.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

pldemon

Re-Hallo,

absolut korrekt. Patches funktionieren – ohne Zweifel. Man sieht es gut beispielsweise beim Linux-Kernel. Auch hier senden die meisten Entwickler ihre Verbesserungen über Patches an die LKML. Diese werden dann zeitnah zumindest besprochen. Dass es bei FHEM auch funktionieren kann, haben wir zusammen schon erfahren. Danke für die Übernahme der Korrekturen nochmals ;)

Ich wollte deshalb nicht eine Diskussion über das Tool starten, sondern euch eher einen Gedankenanstoß über eure Abläufe liefern. Denn als Neuling ist es sehr hart bei euch einzusteigen und ich befürchte, dass ihr dadurch auch Entwickler/Unterstützer verliert. Ich spreche da leider aus meiner Erfahrung. Denn auch ich habe vor einem Jahr aufgegeben und irgendwann meine Korrekturen nicht mehr an euch gesendet. Jetzt, ein Jahr später, habe ich einen zweiten Anlauf gestartet und leider gemerkt, dass es immer noch sehr zeitintensiv ist euch zu helfen.

Gruß,
Mirko

Wzut

@pldemon, ja das Elend kenne ich auch. Für manche Entwickler ist es wohl eine Art Gotteslästerung wenn man Hand an ihren heiligen Code legt.
Besonders wenn es so offensichtlich öffentlich ist wie ein Patch im Forum ist bzw. oft wird es wohl gar nicht gelesen.
Sehr gute Erfahrungen habe ich gemacht indem ich die Leute direkt angeschrieben habe und das Problem erklärt und den Patch gleich mitgeliefert habe.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

justme1968

@pldemon: ich finde den rückschluss von drei (zum teil etwa obskuren) projekten auf alle fhem entwickler etwas gewagt.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968