Autor Thema: Maintainership für Twilight, holidays/* und contrib/sacha_gloor  (Gelesen 960 mal)

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1242
Hallo zusammen,

da ich aktuell und in nächster Zukunft nur wenig Zeit haben werde, gebe ich hiermit die Maintainership für meine Module / Files (d.h. contrib/sacha_gloor, 59_Twilight und holidays/*) auf.

Das gilt ebenso für die Weiterentwicklung von Buienradar.

LG
Christoph Morrison

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16517
  • s/fhem\.cfg/configDB/g
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #1 am: 24 August 2020, 11:01:02 »
Ich würde mich um die holiday files kümmern.
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22806
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #2 am: 24 August 2020, 11:06:48 »
Zitat
Ich würde mich um die holiday files kümmern.
Danke

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11611
  • eigentlich eher "user" wie "developer"
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #3 am: 04 September 2020, 17:37:17 »
Dann würde ich mal "Twilight" rufen, allerdings nur mit einem "orphan" (oder ist das Fehlen des Zusatzes so zu verstehen, dass du, Rudi, das behalten willst?).

Hintergrund: Ich habe sowieso ein paar Kleinigkeiten vorbereitet, damit die seit Jan. 19 erscheinenden Fehlermeldungen wg. des fehlenden Yahoo-Diensts verschwinden, siehe https://forum.fhem.de/index.php/topic,113983.0.html. Eventuell gliedere ich dann auch gleich noch ein paar zentrale Funktionen aus WeekdayTimer/RandomTimer/Twilight mit aus, mal schauen.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22806
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #4 am: 04 September 2020, 19:12:04 »
Zitat
Dann würde ich mal "Twilight" rufen, allerdings nur mit einem "orphan"
Danke!

Zitat
oder ist das Fehlen des Zusatzes so zu verstehen, dass du, Rudi, das behalten willst?.
Nein, das "orphan" habe ich wohl vergessen.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11611
  • eigentlich eher "user" wie "developer"
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #5 am: 11 September 2020, 12:35:02 »
"orphan" habe ich auch mal bei den "sacha_gloor" ergänzt.

Ein paar Anmerkungen:
- Twilight hatte den unschönen Nebeneffekt, dass es seine longitude/latitude-settings nach global geschrieben hat (ohne dass das irgendwo groß erwähnt worden wäre). Das ist m.E. ein Unding und daher zwischenzeitlich auch geändert, was allerdings gleich den Finger auf eine andere Wunde gelegt hat: Twilight hängt indirekt wieder an den globalen Angaben, siehe diese Rückmeldung https://forum.fhem.de/index.php/topic,114061.msg1084450.html#msg1084450.
Beim Versuch, das zu beheben bin ich dann darüber gestolpert, dass die Ermittlung von longitude und latitude in SUNRISE_EL hartvercoded ist. Jetzt kann ich entweder
a) den Code aus SUNRISE_EL als Vorlage nehmen, und den in Twilight versuchen zu adaptieren, dass er die dort angegebenen Parameter auch berücksichtigt;
b) hoffen, dass du (Rudi) SUNRISE_EL (bzw. eigentlich nur sr_alt(), wenn ich das richtig verstehe) so anpaßt, dass es notfalls zwei weitere Parameter für longitude/latitude akzeptiert;
c) die in Twilight angegebenen Parameter ignorieren und den User via Log darauf hinweisen, dass er die Einstellungen bitte in global vorzunehmen hat;
(d) den alten Zustand wiederherstellen)...

Präferenz wäre b) (es sei denn, ich übersehe was wichtiges; an einem patch für SUNRISE_EL kann ich mich bei Bedarf versuchen)...
Damit könnte man auch mehrere Twilight-Devices haben, falls wieder jemand seine tropischen Fische passend beleuchten will (Schon klar, dass Astro das ggf. auch liefern könnte, der Bedarf ist daher eher gering). Leider kann ich auch nicht einfach so die Syntax ändern, da zumindest die Angabe des "indoor_horizon" ja weiter Auswirkungen haben soll, und vor automatischen Änderungen dieser Userangaben schrecke ich zumindest im Moment noch zurück...

- Die Benennung nach irgendwelchen früheren Maintainern (sacha_gloor) ist irgendwie irritierend... Da das sowieso in contrib ist, wäre doch eine Korrektur angezeigt, oder?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22806
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #6 am: 11 September 2020, 12:44:03 »
b) kommt auf TODO, dauert aber je nach Aufgaben bis naechste Woche.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11611
  • eigentlich eher "user" wie "developer"
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #7 am: 11 September 2020, 12:56:27 »
Danke schon mal vorab.
(Das ganze ist auch nicht eilig oder wichtig).

Muß ggf. dann mal checken, ob die in Twilight gesetzten Werte tatsächlich nach global sollen, falls dort bisher noch keine Angaben sind - das könnte je nach Installation nämlich der Fall sein. In diesen Fällen geben dann neuerdings Aufrufe von Funktionen aus SUNRISE_EL andere Werte als erwartet aus, was auch nicht besonders nett ist...
(Aber wenn, gibt das ein ausdrückliches CommandAttr(), damit der betreffende User auch die Chance hat, das für gut zu befinden...).
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 22806
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #8 am: 15 September 2020, 18:21:33 »
Zitat
b) hoffen, dass du (Rudi) SUNRISE_EL (bzw. eigentlich nur sr_alt(), wenn ich das richtig verstehe) so anpaßt, dass es notfalls zwei weitere Parameter für longitude/latitude akzeptiert;
Ich habe die beiden optionalen Parameter $lat,$long zu sr_alt hinzugefuegt. Wenn gesetzt, dann werden nicht die globalen Attribute abgefragt.

Weiterhin einen Fehler gefixt: falls man fuer altitude keinen gueltigen Wert spezifiziert hat, dann wurden die weiteren Parameter (offset, min, max) eins versetzt ausgewertet.

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11611
  • eigentlich eher "user" wie "developer"
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #9 am: 16 September 2020, 09:31:09 »
Danke, update für Twilight ist auch eingecheckt, muss dann aber irgendwann auch wieder etwas in "meinem" Code aufräumen, das war jetzt eher "dass es gemacht ist"...
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

Offline Christoph Morrison

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1242
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #10 am: 16 September 2020, 22:48:59 »
- Die Benennung nach irgendwelchen früheren Maintainern (sacha_gloor) ist irgendwie irritierend... Da das sowieso in contrib ist, wäre doch eine Korrektur angezeigt, oder?

Wie kommst du darauf?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 11611
  • eigentlich eher "user" wie "developer"
Antw:Maintainership für Twilight, holidays/* und contrib/sacha_gloor
« Antwort #11 am: 17 September 2020, 07:49:28 »
Die Betonung sollte auf _früheren_ liegen, sorry, wenn das nicht entsprechend rübergekommen ist.

Grundsätzlich finde ich es völlig ok, wenn in contrib sehr lockere Regeln gelten, auch was die Doku des dortigen Codes etc. angeht. Aber spätestens, wenn Inhalte/Module da in eine allgemeine Verwaltung übergehen (wie betreffende "orphans"), sollte man sich m.E. wirklich überlegen, wie man damit umgehen will.

Da ich nicht nur motzen will, vielleicht ein Vorschlag (ohne das jetzt schon groß ausgefeilt zu haben, einfach als Diskussionsgrundlage):
- "sacha_gloor" wird in "orphan" umbenannt. Damit ist (noch) klarer, dass das (wie "deprecated") nicht wirklich aktiv gepflegt ist.
- ggf. sollte man "contrib" insgesamt mal durchsehen, ob da noch mehr rumliegt, was (vom Status her) in "orphan" gehört
- Ggf. könnte es eine Variante von commandref_modular.pl geben, mit deren Hilfe man dann eine Art "Überblicksdoku" über das erstellen könnte, was in den drei Verzeichnissen contrib, contrib/orphan und contrib/deprecated steht und die Abschnitte entsprechend benennen?
- Wunsch an alle Betreuenden von dortigem (.pm- und .pl-?) content wäre dann, zwar nicht unbedingt eine commandref einzuflegen, aber wenigstens sowas wie eine Kurzbeschreibung ("item summary"?) (bei den hier in Rede stehenden Modulen scheint es durchgängig sogar eine cref zu geben).

Sonst entsteht eventuell auch der Eindruck, dass es für Maintainer-Interessenten Pflicht wäre, das Verzeichnis, also alle fraglichen Module zu übernehmen; das wäre tendenziell nicht zielführend...

Wie gesagt, kein fertiges Konzept, aber irgendwie wäre eine (aus Usersicht) übersichtlicherer "Zugang" hilfreich. (Aber evtl. übersehe ich auch mal wieder was).

Just my2ct.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | BT@OpenMQTTGateway
svn:MySensors, WeekdayTimer, RandomTimer, Twilight,  AttrTemplate => {mqtt2, mysensors, zwave}

 

decade-submarginal