Hauptmenü

@RichardCZ

Begonnen von Byte09, 31 März 2020, 05:17:20

Vorheriges Thema - Nächstes Thema

CoolTux

Ich habe Thomas um ein persönliches Gespräch gebeten. Ich denke es wäre für die FHEM Community schade wenn wir ihn als Entwickler und Helfer verlieren würden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

KernSani

Kann mir mal jemand erklären, warum die ganzen Diskussionen hier so emotional geführt werden?
Können wir uns mal darauf einigen, sachlich zu diskutieren oder - wem das aufgrund der Eigenheiten des Mods schwerfällt - die Perl-Ecke einfach zu ignorieren?
Das soll kein Freibrief für Richard sein, aber ignorieren wir doch das ganze Geschwurbel erstmal solange es nicht persönlich wird und konzentrieren uns auf die inhaltlichen Dinge.


Gesendet von iPhone mit Tapatalk
RasPi: RFXTRX, HM, zigbee2mqtt, mySensors, JeeLink, miLight, squeezbox, Alexa, Siri, ...

CoolTux

@Richard
Würdest Du der Bitte von Thomas nachkommen? Beide Module werden ausschließlich von einem kleinen Nutzerkreis verwendet. In Deiner Umgebung werden sie sicherlich keine Nutzung finden.
Ich denke es wäre eine gute Geste Thomas gegenüber.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

RichardCZ

#18
Zitat von: CoolTux am 31 März 2020, 10:10:08
@Richard
Würdest Du der Bitte von Thomas nachkommen? Beide Module werden ausschließlich von einem kleinen Nutzerkreis verwendet. In Deiner Umgebung werden sie sicherlich keine Nutzung finden.
Ich denke es wäre eine gute Geste Thomas gegenüber.

Hm. Ich finde, man hätte sich hier viel ersparen können, denn ein SVN update zeigt

$ svn up
Updating '.':
D    trunk/fhem/FHEM/98_MSwitch.pm
D    trunk/fhem/www/pgm2/MSwitch_Wizard.js


was bedeutet, dass Hobo beim nächsten Commit ohnehin damit synct.
Ich habe nicht wenig Hirnschmalz aufgewendet um FHEM und Hobo so lange es geht in-sync zu halten (keine Spaltung).

edit:

done.
https://gl.petatech.eu/root/HomeBot/-/commit/862c0594122a8a8bd21e2fe8acd8965ad06b7d38
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Martin Fischer

Zitat von: CoolTux am 31 März 2020, 10:10:08
@Richard
Würdest Du der Bitte von Thomas nachkommen? Beide Module werden ausschließlich von einem kleinen Nutzerkreis verwendet. In Deiner Umgebung werden sie sicherlich keine Nutzung finden.
Ich denke es wäre eine gute Geste Thomas gegenüber.

Mit Verlaub: Das ist doch Bullshit! Es geht hier um das Projekt FHEM mit mehr als 20k+ Anwendern.

Einen unter GPL stehenden Quelltext aus dem Projekt zu entfernen, weil man persönliche Befindlichkeiten gegenüber einer oderer mehreren Personen hat, bedeutet gleichzeitig auch, dass das Projekt nicht im Vordergrund steht. Selbiges ist auch dem Verhalten zuzuschreiben, das die Module aus dem FHEM SVN entfernt werden und nur noch manuell eingebunden werden.

Hier erschwert man den Anwendern den Zugang zu der Funktionalität. Es ist also keine "Backpfeife" an RichardCZ (oder anderen "Nasenfaktoren"), sondern an die Community. Ginge es dem Entwickler um das Projekt FHEM, das ja auch er in seiner Gänze und ohne Einschränkungen nutzt, dann würde er über "der Sache" stehen und den Quelltext seiner Module dort lassen, wo sie für die Community sein sollten: im FHEM SVN.

Würde dieses Schule machen, dann dürfte man sich einige Module aus irgendwelchen (unsicheren?) Repositories ziehen müssen. Ist das der neue Weg, den FHEM gehen will?
--
Admin, Developer, Gründungsmitglied des FHEM e.V.

marvin78

Natürlich ist das Bullshit. Ein Gespräch darüber, in dem man vernünfig diskutiert und nicht mit Keulen droht, wäre angebracht. Nicht mehr und nicht weniger. Es ist wie im Kindergarten hier.

andies

Ich habe hier Schreibberechtigung, weil ich ein Modul mal geschrieben habe (nochmal dank an CoolTux für seine Hilfe und leider, Richard, ist da einiges im Argen - mein Fehler), obwohl ich ein ziemlicher Noob bin. Wenn das hier eine Runde am Arbeitsplatz wäre, würde ich vorschlagen, dass wir das Schreiben unterbrechen und uns mündlich austauschen. In so einem Forum bekommen schnell dahingesagte Worte eine Bedeutung, die sie im Gespräch nicht haben. Dadurch schaukeln sich Situationen schnell auf.

Vielleicht können wir hier das machen, was wir sowieso tun: Social Distancing für ein paar Tage oder Stunden. Also nichts sagen und vor allem nichts schreiben, obwohl das Forum und insbesondere dieser Thread offen bleibt. Wir halten alle die Luft an, um diesen Virus vorbeiziehen zu lassen.

Mir ist auch nicht ganz klar, wieso es zu dieser Emotionalität kommt. vielleicht deshalb, weil wir das alle freiwillig und in unserer Freizeit machen und jede Anmerkung (ich will nicht sagen Kritik!) daran als Angriff auf die Person und nicht die Sache interpretiert wird - auch wenn das gar nicht so gemeint ist. Ich lese Richards Beiträge mit großem Interesse, ich lerne eine Menge. Ich würde mir wünschen, dass er dran bleibt (das ist, wie gesagt, mein Interesse). Aber es scheint so zu sein, dass hier nicht nur Wahrheiten, sondern sogar Auffassungen aufeinander prallen, die doch fundamental verschieden sind. Ich weiß nicht, wie man so etwas in einem Forum in den Griff bekommt.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

zap

Zitat von: RichardCZ am 31 März 2020, 09:56:43
Jeder möge sich bitte in Ruhe überlegen ob er den Konflikt und eine Spaltung möchte. Denn ehrlich gesagt glaube ich nicht, dass Hobo technologisch den Kürzeren ziehen würde und es würde mir viel leichter fallen weitere kompetente Mitstreiter zu Hobo zu holen als zu FHEM.

Könntest Du diese Aussage etwas konkretisieren? Ziehst Du eine Abspaltung von Hobo als FHEM-Klon in Erwägung? Muss ich mich als Modulentwickler zukünftig zwischen FHEM und Hobo entscheiden?
Wenn ja, entscheide ich mich vermutlich für ioBroker oder OpenHab oder ...
So eine Aufspaltung habe ich schon mal in einem anderen Opensource Projekt erlebt. Keiner der beiden Zweige existiert noch.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

betateilchen

Zitat von: RichardCZ am 31 März 2020, 09:56:43
Ich werde mich hiermit aus diesem Thread zurückhalten und bin heilfroh, dass ich die Moderation an CoolTux abgegeben habe

Dann könnte man doch nun eigentlich dieses gesamte Unterforum wieder verschwinden lassen...
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

CoolTux

Zitat von: betateilchen am 01 April 2020, 18:22:03
Dann könnte man doch nun eigentlich dieses gesamte Unterforum wieder verschwinden lassen...

Warum? Ob Du es glaubst oder nicht aber fur einigen Entwicklern war dieses Forum bereits hilfreich.
Ich würde es sehr schade finden.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

zap

Man muss nur aufpassen, dass der Schaden nicht größer wird als der Nutzen.
2xCCU3, Fenster, Rollläden, Themostate, Stromzähler, Steckdosen ...)
Entwicklung: FHEM auf AMD NUC (Ubuntu)
Produktiv inzwischen auf Home Assistant gewechselt.
Maintainer: FULLY, Meteohub, HMCCU, AndroidDB

CoolTux

#26
Ich bilde mir ein jeder Entwickler weiß wo sein Herz schlägt. Bei mir weiß ich es zu mindest, meines wird immer für FHEM schlagen. Für mich gibt es keine Alternativen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

betateilchen

Zitat von: zap am 01 April 2020, 18:39:48
Man muss nur aufpassen, dass der Schaden nicht größer wird als der Nutzen.

Danke - wenigstens einer, der das gerade durch dieses Unterforum entstehende Problem ebenfalls erkannt hat.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

KölnSolar

Hier ist noch einer.  :-X
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

herrmannj

#29
ich sehe dieses Thema komplett un-emotional.

Zuerst sind wir GPL da ist ein fork fast normal, quasi state-of-the art. (wer würde schon langweilige Projekt forken)

Zweitens ist die Code Base von FHEM, zumindest in Teilen, irgendwas um die 10 Jahre alt. Vielleicht sogar mehr, keine Ahnung, war weit vor meiner Zeit.

Das bedeutet bei zig tausend Benutzern, über die die Zeit, vor allem eins: der code hat schon alles gesehen. Wirklich alles. Und wenn da ein bug war dann wurde er, dank der riesigen community, gemeldet .. und gefixt. Das mag nicht immer schön aussehen aber es ist eins. Effizient. Und man darf sich da nichts vormachen, Testsuite hin oder her. Da sind immer bugs drin. Welche die erst nach Jahren auftreten. Das alles hätte ein fork _noch  vor sich_! villariba und villabajo. Feiert schon da waschen die anderen noch ab.

Dazu kommt das besondere Einsatzbild von Home Automation Software. Das ist eben kein Spiel dass, wenn es abstürzt, vom user neu gestartet wird, kurzes grummeln, weiter gehts. Warum sind denn die meisten, auch unter den devs, solche fhem update muffel? Weil jeder weiß was für einen Stress es mit der Familiy gibt wenn das Ding mal Amok läuft. Keine Experimente! Happy wife, happy life. Sprich, Du findest keine kritische Masse die masochistisch ist sich in der Anwendung auf Experimente einzulassen. Ist genau das woran hier der devel branch gescheitert ist.

Ich denke man darf hier auch den therapeutischen Nutzen für quarantänte geschädigte perl Gurus nicht unterschätzen. ;) Ich hab das aber schon mal gesagt; in der Tat finde ich es Schade das die Arbeit in großen Teilen zwangsläufig für die Katz ist. Hätte ich die Zeit und das Wissen würde ich es anders einsetzen. Aber: die Aktivitäten hier in der perl Ecke, das push and pull in Bezug auf die perl skills bei Einigen - das ist auch ein Gewinn, daher ist das (trotz Stress und gequengel) auch so ein win!

Und wenn jetzt ein Dev wegen dem bissl wegläuft. Schade, aber das wäre morgen aus anderen, genauso nichtigen, Umständen vermutlich sowieso passiert. OpenHab etc; ja das sind auch tolle Projekte. Aber Leutz, schaut Euch da um - die kochen auch nur mit Wasser. Auf der anderen Seite der Brücke ist die Wiese halt immer grüner ;)

Edit:

Hier, ich häng mal direkt den Beweis für meine These an: https://forum.fhem.de/index.php/topic,109776.msg1037608.html#msg1037608
Und nein, ich habe das weder bestellt noch dafür bezahlt  ;D