Hallo Rudi,
Ich würde gerne einen Maintainerwechsel anfragen/diskutieren.
In meinen Augen wäre es sinnvoll den Maintenance von SUNRISE_EL vom selben Team machen zu lassen welches auch das Astro Modul verwaltet.
Dann könnte man nämlich SUNRISE_EL komplett auf die Astro Berechnung umstellen - ganz ohne ein ersetzen der Funktion. Da SUNRISE_EL schon ein eigenes Modul ist und der Kompatibiltäts-Code schon da ist, ist das keine große Sache mehr und mehr eine Frage von Copy&Paste nach 99_SUNRISE_EL.pm.
Grüße
Marko
Soweit ich sehe, ist das Astro Modul ein erweitertes SUNRISE_EL, also ein (im positiven Sinne) Konkurrenzprodukt.
Warum sollten wir den kleineren Konkurrenten eliminieren?
"Weil es einfach ist", ist fuer mich noch kein valides Argument :)
Zitat von: rudolfkoenig am 05 Juli 2019, 08:33:55
Soweit ich sehe, ist das Astro Modul ein erweitertes SUNRISE_EL, also ein (im positiven Sinne) Konkurrenzprodukt.
Warum sollten wir den kleineren Konkurrenten eliminieren?
"Weil es einfach ist", ist fuer mich noch kein valides Argument :)
Das hast Du falsch gelesen. Nicht eliminieren sondern sogar erweitern. Aktuell wurde gestern Code in Astro zugefügt welcher eigentlich nur SUNRISE_EL erweitern soll. Kleiner Wrapper.
Aber es wäre besser wenn der Code direkt in SUNRISE_EL laden würde. Im Zuge der Überlegung ist halt aufgefallen das es Sinn machen könnte die Maintainance zusammen zu legen.
Weg kommt nichts ;D
Grüße
Warum will Modul A (Astro) Modul B (SUNRISE_EL) erweitern?
Was spricht gegen einen Patch nach herkoemmlicher Art?
Ich sperre mich nicht gegen Neuerungen, aber ich wuerde gerne wissen, warum ich was mache.
Zitat von: rudolfkoenig am 05 Juli 2019, 09:07:21
Warum will Modul A (Astro) Modul B (SUNRISE_EL) erweitern?
Was spricht gegen einen Patch nach herkoemmlicher Art?
Ich sperre mich nicht gegen Neuerungen, aber ich wuerde gerne wissen, warum ich was mache.
Genau darum geht es ja eigentlich. Astro will SUNRISE_EL ja nicht erweitern. Ok aktuell tut es das. Aber genau das wollen wir ändern. Wir wollen eine durch weg klare Linie haben. Eine Konsistenz. Die Entwickler arbeiten mit eigenen Routinen weil sie bessere Ergebnisse erzielen. Statt den Code für die besseren Ergebnisse in die bereits vorhandenen Funktionen ein zu pflegen. Beispiel SUNRISE_EL.
Es spricht natürlich nichts gegen einen Patch auf herkömmlichen Weg. Die Frage war halt nur ob die Leute welche aktuell sich eh intensive mit Astro beschäftigen nicht auch gleich die Pflege von SUNRISE_EL übernehmen könnten um dann dort etwaige Erweiterung einpflegen zu können.
Es geht also
1. darum SUNRISE_EL als zentrale Stelle für einige Astro Daten zu erweitern
2. um die Frage ob es nicht Sinn macht den Leuten das Maintainance von SUNRISE_EL zu überlerlassen die eh schon den ganzen Tag mit den Sternen jonglieren ;D
Aber wie gesagt, einen wirklichen festen harten Standpunkt und Grund gibt es nicht und ist eher als leichte Anfrage zu verstehen.
Grüße
ZitatAstro will SUNRISE_EL ja nicht erweitern. Ok aktuell tut es das.
Ach. Das ist nicht nett. Warum muss der kleine Konkurrent gegaengelt werden?
ZitatDie Frage war halt nur ob die Leute welche aktuell sich eh intensive mit Astro beschäftigen nicht auch gleich die Pflege von SUNRISE_EL übernehmen könnten um dann dort etwaige Erweiterung einpflegen zu können.
Also wird der Astro-Code in SUNRISE_EL kopiert, danach fragt man sich, wozu SUNRISE_EL gut ist, ist ja schliesslich der gleiche Code der vom gleichen Person doppelt gepflegt werden muss, also wird SUNRISE_EL erst deprecated dann entfernt.
Es mag sein, dass SUNRISE_EL nicht die gleichen Zahlen liefert wie irgendwelche Internet-Portale, aber ich habe damit seit 10 Jahren kein Problem.
Wen es stoert, der darf gerne Astro einsetzen, dafuer ist ja Konkurrenz da.
Hallo Rudi,
Vielen Dank für die Diskussion. Dann nehme ich das so mit und wir lassen es wie es ist.
Hab noch einen schönen Tag.
Grüße
Marko
Die ursprüngliche Motivation für Astro war, genauere Daten mit mehr Optionen zu haben - fein. Ein Herauswurf von SUNRISE_EL war von mir nie beabsichtigt.
Jetzt sind Loredo und CoolTux mit in die Maintenance eingestiegen, damit erweitert sich auch ein wenig der Fokus. Ich muss aber Rudi an der Stelle Recht geben: Das alte Modul sollte deswegen nicht gleich aufgegeben werden.
In Anbetracht der Länge und Heterogenität der CommandRef bräuchten wir aber eine weiter gehende Klassifikation von Modulen (habe ich schon vor Jahren angeregt...), so dass ein Suchender unter dem Stichwort "Sonnenaufgang" sowohl SUNRISE_EL als auch Astro finden kann.
Ultimativ könnte dann natürlich das (durchsuchbare) Stichwortverzeichnis auch ermöglichen, unter einer Gerätebezeichnung alle eventuell damit zu verwendenden Module zu finden.
Machen wir es konkret: Ich schlage hiermit vor, das FHEMWiki durch diesen Zusatz hier zu semantisieren, dann können wir diese Klassifikation dort einführen:
https://www.semantic-mediawiki.org/wiki/Semantic_MediaWiki
LG
pah
Hallo,
Um es noch einmal ganz klar zu sagen. Es ging nie darum SUNRISE_EL auf zu geben. Ich hatte es hoffentlich (mehrmals) deutlich gemacht. Funktionen in SUNRISE_EL sollten erweitert werden. Der Code dafür lag bereits in Astro und hätte nur nach SUNRISE_EL umkopiert werden müssen. Das war alles.
Grüße
Zitat von: Prof. Dr. Peter Henning am 11 Juli 2019, 12:05:17
In Anbetracht der Länge und Heterogenität der CommandRef bräuchten wir aber eine weiter gehende Klassifikation von Modulen (habe ich schon vor Jahren angeregt...), so dass ein Suchender unter dem Stichwort "Sonnenaufgang" sowohl SUNRISE_EL als auch Astro finden kann.
Das geht über die Metadaten direkt in FHEM, wahrscheinlich hast du deshalb auch gefragt.
Man muss keine doppelten Daten in einem separaten Wiki dafür pflegen, das geht unmittelbar direkt "an der Quelle".
In Astro habe ich auch schon Suchwörter hinzugefügt, die wir beliebig ergänzen können. Wenn du "search sun" eingibst, bekommst du schon entsprechende Ergebnisse.
Rudi kann in 99_SUNRISE_EL.pm ebenfalls eigene Suchwörter einfügen, wenn er das möchte.
(Hinweis: Die leicht anderen Meta Informationen für Astro sind durch meine Entwicklungsumgebung verursacht, bei der Astro nicht aus dem SVN kommt, sondern aus dem Github Repository. Deshalb wird das dort auch so wiedergegeben, beispielsweise beim "Release Status".)