Ich möchte hier ein Thema ansprechen, das mich in letzter Zeit mehr als irritiert.
Mein PR für eine neue Version des smartEQ SOC Moduls ist seit April offen.
Ein weiterer PR für ein neues SOC-Modul für OVMS ist seit Mitte Juli offen.
In beiden PR wurden Reviews durchgeführt und daraus resultierende Änderungen von mir gemacht.
Aus meiner Sicht ist alles erledigt.
Trotzdem herrscht seit Wochen/Monaten Funkstille.
Ich verstehe, dass es wichtigere Baustellen gibt und dass die Urlaubszeit zu Verzögerungen führt.
Andererseits sollten solche Module zeitnah im Master verfügbar werden um von der Community getestet werden zu können
solange ich als Entwickler noch im Thema bin.
Letztlich stellt sich mir die Frage:
Soll sich Community SOC-Module weiterhin entwickeln (und supporten) oder nicht?
Sind SOC-Module in 2.x aus der Community noch erwünscht?
Re: Sind SOC-Module in 2.x aus der Community noch erwünscht?
Ja, das ist ausdrücklich weiterhin erwünscht.
Das OVMS-Modul ist im Review mit "approved" markiert worden, dh die Änderungen sind so in Ordnung und werden gemergt. Allerdings kommt die Änderungen erst in die nächste Version, weshalb der Pull Request mit dem Meilenstein 2.1.6 markiert ist. Um eine stabile Version zu erhalten, ist es vor einem Release erforderlich, ab einem bestimmten Zeitpunkt keine neuen Änderungen mehr zu mergen, sondern nur noch auftretende Fehler zu beseitigen.
Das SoC-Modul ist im Status "Changes Requested", dh die Änderungen werden so nicht gemergt. Ich habe Dich mehrfach darauf hingewiesen, die utils.py zu entfernen und dies auch begründet.
Die Einführung eines Logmanagers ist bei dieser Software-Größe nicht unüblich. Allerdings gibt es kaum Mehrwert, wenn der Logmanager nur von einem Modul verwendet wird und der Rest der Software ein anderes Logging verwendet. Das erzeugt am Ende nur Mehraufwand.
Wir legen großen Wert auf die Lesbarkeit und Erweiterbarkeit von software2. Der Code soll konsistent sein und möglichst wenig Redundanz aufweisen. Wenn jedes Modul seine eigene Umgebung verwendet und nicht die allgemeine, muss man sich bei jedem Modul einzeln einarbeiten und einzeln pflegen. Das ist nicht das Ziel. Deshalb achten wir beim Review von PullRequest konsequent darauf, dass die Module konsistent sind.
Das OVMS-Modul ist im Review mit "approved" markiert worden, dh die Änderungen sind so in Ordnung und werden gemergt. Allerdings kommt die Änderungen erst in die nächste Version, weshalb der Pull Request mit dem Meilenstein 2.1.6 markiert ist. Um eine stabile Version zu erhalten, ist es vor einem Release erforderlich, ab einem bestimmten Zeitpunkt keine neuen Änderungen mehr zu mergen, sondern nur noch auftretende Fehler zu beseitigen.
Das SoC-Modul ist im Status "Changes Requested", dh die Änderungen werden so nicht gemergt. Ich habe Dich mehrfach darauf hingewiesen, die utils.py zu entfernen und dies auch begründet.
Die Einführung eines Logmanagers ist bei dieser Software-Größe nicht unüblich. Allerdings gibt es kaum Mehrwert, wenn der Logmanager nur von einem Modul verwendet wird und der Rest der Software ein anderes Logging verwendet. Das erzeugt am Ende nur Mehraufwand.
Wir legen großen Wert auf die Lesbarkeit und Erweiterbarkeit von software2. Der Code soll konsistent sein und möglichst wenig Redundanz aufweisen. Wenn jedes Modul seine eigene Umgebung verwendet und nicht die allgemeine, muss man sich bei jedem Modul einzeln einarbeiten und einzeln pflegen. Das ist nicht das Ziel. Deshalb achten wir beim Review von PullRequest konsequent darauf, dass die Module konsistent sind.
-
rleidner
- Beiträge: 1112
- Registriert: Mo Nov 02, 2020 9:50 am
- Has thanked: 8 times
- Been thanked: 56 times
Re: Sind SOC-Module in 2.x aus der Community noch erwünscht?
Hallo Lena,
vielen Dank für die Rückmeldung.
Zum smartEQ-Modul habe ich im PR geantwortet.
vielen Dank für die Rückmeldung.
Zum smartEQ-Modul habe ich im PR geantwortet.
openWB-2 Standard+ | openWB EVU Kit v2 MID| 9,9kWp mit Kostal Plenticore 8.5 plus | VW ID.3, Kia EV6, Smart EQ forfour