Optimierung Kunden-Feedback - Entwicklung

[raffix]

Hallo Raffix,

ich kann deinen Frust ein Stück weit nachvollziehen.

[...]

Wir sind dankbar für jegliches Feedback, aufgrund der großen Nutzerbase müssen wir die Abläufe aber auch koordinieren. Ich bitte hier um etwas Verständnis.

Vielen Dank für dein Verständnis und deine Offenheit für Feedback.

Ich habe kein Problem mit Bugs in neuen Features, ich habe ein Problem damit, dass Bugs immer wieder in alten Features auftauchen, so dass es keine stabilen Versionen mehr gibt. Die Lösung ist simpel:
Pflege einer stabilen Version mit Patchreleases, so lange bis die gröbsten Schnitzer raus sind und parallel dazu die nächste Version entwickeln, aber die vorherige Version wird immer noch gepflegt (für einen längeren Zeitraum als heute). Das ist etwas aufwändiger für die Entwicklung (lohnt sich aber meiner Meinung nach) und löst das Problem in weiten Teilen. Es gäbe dann zwei Release-Zweige (stable und Early-Adopter)

Als Nutzer entscheidet man sich bewusst für den stabilen oder Early-Adopters-Pfad. Der Early-Adopters-Pfad wäre der heutige stable. Der mit Patchreleases versorgte Branch wäre dann der neue echte stable.

PS: Ich sehe gerade, dass Gero und andere das LTS genannt haben. Mir würde auch ein längerer Releasezyklus helfen. Entscheidend ist, dass das heutige stable länger ausentwickelt und solange mit Patches versorgt wird, bis man es wirklich als stabile Version produktiv einsetzen kann.

[Thomas aus W]

Womöglich könnte das OWB-Team auf dieses git-Branch-Modell wechseln:
https://nvie.com/posts/a-successful-git ... ing-model/

Der wesentliche Unterschied zu heute ist, dass es explizite Releas-Branches (=FeatureFreese) gibt in denen es nur noch Bugfixes integriert werden.

Bei den Hotfixes könnte man noch je nach Schwere noch entscheiden, ob der wirklich direkt in den Delivery-Branch kommt oder erstmal nur in den dev und dann mit dem nächsten release ausgeliefert wird.


bye
TW

[KLez]

Ich hab mir hier zwar nicht alles durchgelesen, aber das sind alles Theman die ich in diesem Forum schon hundertfach angesprochen habe. Die OpenWB Entwicklung krankt einfach an allem was eine professionelle Software-Entwicklung ausmacht. Seit Jahren immer und immer wieder die gleichen Themen und Probleme.

1.) Ihr betreibt KEIN geordnetes Bug-Tracking! Ihr besprecht Bugs völlig ungeordnet im Forum, wo jeder querbeet seinen Senf abgeben kann, auch wenn es mit dem Problem eventuell nichts zu tun hat. Warum verwendet ihr nicht GIthub dafür?! Ich verstehe es nicht! Das bringt alles mit was es dafür braucht! Lösung: Führt endlich ein geordnetes Bug-Tracking ein! Ihr habt aktuell überhaupt keinen Überblick darüber, ob ein Bug neu hinzugekommen ist, oder schon länger existiert.

2.) Ihr führt offensichtlich keinerlei oder nur ungenügende Unit-Tests durch! Anders ist es nicht zu erklären, warum es immer wieder schwerwiegende Bugs in den Stable / Release Branch schaffen. Lösung: Entwickelt in Feature-Branches und testet diese einzeln auf Herz und Nieren bevor ihr einen riesigen Pull-Request mit Breaking-Changes als "Beta" macht. Ihr lauft den Problemen sonst immer nur hinterher.

3.) Ihr entwickelt ständig auf Basis einer veralteten Python Version (3.9). Mittlerweile sind zig Methoden und Libs deprecated. Ihr schiebt diesen riesigen Berg an Migrations-Arbeit zu einer neuen Python Version seit Jahren vor euch her, obwohl dabei das Problem ständig nur größer wird. Das ist euch offensichtlich überhaupt nicht klar?! Lösung: Führt regelmäßige Update-Zyklen eurer Basis durch!

3.1.) Selbiges gilt für eure zugrundeliegende Debian 11 Version! Die ist seit August 2024 EOL und ein Sicherheitsrisiko! Man kann jetzt drüber streiten inwiefern das bei einer Wallbox gefährlich ist, aber das ändert nichts an dem eigentlichen Problem.

4.) Die aktuelle Architektur von OpenWB macht es praktisch unmöglich die Software als Docker bereit zu stellen. Für moderne Software-Entwicklungen ist das eigentlich ein No-Go. Lösung: Es gibt keine solange OpenWB so gebaut ist, wie es ist.

5.) Eure Versionierung ist in meinen Augen konzeptlos! 2.1.8 ist ein Breaking Change gewesen und nicht abwärtskompatibel zu 2.1.7. Die Versionsnummer lässt aber ein harmloses Bug-Fixing vermuten. Es spielt keine Rolle ob und wie ihr das kommuniziert habt! Es kann nicht sein, dass man bei jedem Update erstmal im Forum lesen muss was Sache ist! Lösung: Haltet euch an einfachste Standards! 1te Ziffer für Major Versionen, 2te für Minor Versionen und die 3te für Bug-Fixes!

Es gibt noch zig andere Dinge die ich hier kritisieren kann / könnte, aber die Diskussion habe ich wie gesagt schon mehrfach durch.
Solange die oben genannte Punkte nicht grundlegend abgestellt sind, macht es keinen Sinn sich Gedanken über Branching Konzepte oder Kunden-Feedback zu machen, weil die Probleme immanent Hausgemacht sind.

Und das sind sogar nur Themen die die Software-Entwicklung an sich betreffen. Von den hunderten anderen Baustellen wie UI, Bedienung, sinnlose Profil Konzepte usw. usw. rede ich da noch gar nicht.

[schrej]

Die OpenWB Entwicklung krankt einfach an allem was eine professionelle Software-Entwicklung ausmacht.

Das kann ich nur unterstreichen.
Nicht zu vergesssen auch die MQTT Schnittstelle, die aus meinen Augen völlig unstrukturiert entwickelt und auch niemals wirklich dokumentiert wurde. Und nun kam mit "SimpleAPI" noch eine weitere Schnittstelle dazu, die auch noch geflegt werden muss.

[openWB]

Und nun kam mit "SimpleAPI" noch eine weitere Schnittstelle dazu, die auch noch geflegt werden muss.

Eher ist das die Schnittstelle um einen einfachen Zugang zu ermöglichen.
Schließlich hat sich damit die HA Anbindung auch erheblich vereinfacht und verbessert.
In meinen Augen ein großer Schritt für unbedarfte nach vorne.

[ChristophR]

Und nun kam mit "SimpleAPI" noch eine weitere Schnittstelle dazu, die auch noch geflegt werden muss.

Eher ist das die Schnittstelle um einen einfachen Zugang zu ermöglichen.
Schließlich hat sich damit die HA Anbindung auch erheblich vereinfacht und verbessert.
In meinen Augen ein großer Schritt für unbedarfte nach vorne.

Soweit ich das überblicke, ist diese auch dokumentiert.
Könnte man bei aller Kritik ruhig auch erwähnen.

[Gero]

Nicht zu vergesssen auch die MQTT Schnittstelle, die aus meinen Augen völlig unstrukturiert entwickelt und auch niemals wirklich dokumentiert wurde.

Die MQTT-Schnittstelle ist insofern unstrukturiert, als dass sie einfach nur die internen Datenstrukturen rausreicht und niemals als Schnittstelle konzipiert und entwickelt wurde. Sie ist also schon strukturiert, allerdings für den internen Gebrauch der openWB-Software.

[openWB]

Generell werde ich einige Punkte mitnehmen und intern besprechen sowie hier dann auch kommentieren.

Leider entwickelt es sich hier an manchen Stellen zu einem Bashing in Kombination mit Unterstellungen ohne in irgendeiner Form echte Einblicke zu haben.

Das finde ich äußerst schade und erschwert eine konstruktive Diskussionsrunde und damit Verbesserung ungemein.

Vor allem bringt es ja nichts.

Hört das nicht auf werde ich den Thread löschen und gerne mal ein Community Meeting einberufen.
Das hat damals mit der Speichersteuerung auch sehr gut geklappt.

[seaspotter]

Generell werde ich einige Punkte mitnehmen und intern besprechen sowie hier dann auch kommentieren.

Leider entwickelt es sich hier an manchen Stellen zu einem Bashing in Kombination mit Unterstellungen ohne in irgendeiner Form echte Einblicke zu haben.

Das finde ich äußerst schade und erschwert eine konstruktive Diskussionsrunde und damit Verbesserung ungemein.

Vor allem bringt es ja nichts.

Hört das nicht auf werde ich den Thread löschen und gerne mal ein Community Meeting einberufen.
Das hat damals mit der Speichersteuerung auch sehr gut geklappt.

Das der Ton nicht immer mit der besten Kommunikationsform daherkommt muss man sicher manchmal einfach ausblenden.
Aber die enthaltene Kritik, die ja aber schon auch diverse Mal im Forum von verschiedensten Personen auftaucht: Thema veraltete Libs und Software, fehlende Tests und undurchsichtige Versionierung da habt ihr aber auch nie Stellung zu bezogen. Wenn ihr das widerlegen könnt und es dafür Gründe gibt, dann legt die doch einfach dar um diese Kritik auszuräumen. Wenn ihr das wiederholt nicht tut, dann gebt ihr dieser Kritik doch indirekt einfach Recht, dass es so ist und befeuert sie damit.
Wenn sie berechtigt ist, ist das doch auch okay und Grund genug diese Aufzunehmen und daran zu arbeiten und zu sagen: Ja stimmt, nehmen wir mit und versuchen daran zu arbeiten.

Für mich ist der Tenor klar:
- Die User wollen mit Prio 1 eine stabile Grundsoftware mit Basisfunktionialitäten die funktionieren und nicht mit jeder neuen Version die Gefahr besteht, das sich wieder Bugs einschleichen. Das ist heute einfach aktuell nicht gegeben (Thema Phasenumschaltung). Saubere Tests vor Release durchführen und neue Features hinten anstellen.
- Prio2: Thema Bugtracking, Github Issues da muss mehr von eurer Seite der Fokus gelegt werden und der Prozess besser werden. Und je mehr ich drüber nachdenke ob da Community-Support sinnvoll ist, je mehr komme ich zu der Erkenntnis: Das ist eure Aufgabe, eure Software, das könnt und müsst ihr selbst leisten. Ihr könnt nicht eure Arbeit an die Community, ans Forum "abgeben" und die Arbeit abwälzen. Dann müssen die Prios verschoben werden und sich jemand als Hauptaufgabe darum kümmern. Genauso das Github Repo pflegen, es kann nicht sein das Issues und PRs seit Monaten unbearbeitet und offen sind, dann müssen sie geschlossen werden. Genauso wochenlang keine Rückmeldung zur PRs und Issues dürfen nicht sein.

Und danach kann man sich um Weiterentwicklung, neuer Features kümmern. Und ich denke da geht der Großteil der Community absolut mit und ihr stoßt auf großes Verständnis.

[ChristophR]

Womöglich könnte das OWB-Team auf dieses git-Branch-Modell wechseln:
https://nvie.com/posts/a-successful-git ... ing-model/

Der wesentliche Unterschied zu heute ist, dass es explizite Releas-Branches (=FeatureFreese) gibt in denen es nur noch Bugfixes integriert werden.

Bei den Hotfixes könnte man noch je nach Schwere noch entscheiden, ob der wirklich direkt in den Delivery-Branch kommt oder erstmal nur in den dev und dann mit dem nächsten release ausgeliefert wird.


bye
TW

Im groben wäre das ja die Idee einer LTS Version.
Der master Zweig wäre dann die "besonders stabile Version", was ich ganz gut fände, da es ja der Standard ist.
Das Beiwerk mit Hotfixes muss aber m.E. nicht sein.
Man müsste nur einen Extra Zweig für die aktuelle Entwicklung, die jetzt im master Zweig läuft einziehen. Release haben wir ja schon, aus dem dann der master ausgekoppelt wird, wenn alles passt.

Generell ist aber die Frage, was mit Änderungen, die durch die Hersteller (Fahrzeug-SoC, WR-Firmware etc.), die zu einer Fehlersituation führen, passiert.
Auch die Pflege des Colors Themen, das ja durch die Community erfolgt, müsste getrennt betrachtet werden.
Dadurch wird die schöne Theorie wieder über den Haufen geworfen.

P.S: Dass die "Meckerköppe" den Thread zum Anlass nehmen, war ja leider zu erwarten, können wir aber professionell ignorieren, wenn es nicht konstruktiv ist.