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 wie wild 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.