Die Abwägung ist ganz einfach: Ziel sollte es sein keine Regressionen zu haben. Wenn irgendwas nicht funktioniert was in der letzten Version funktioniert hat, dann sollte die neue Version der Komponente einfach noch nicht ausgeliefert werden. Es wird so lange der alte Code ausgeliefert, bis mindestens all das geht was in der letzten Version funktioniert hat.
Ich mach dir jetzt mal ein einfaches Beispiel aus aktueller KWin Entwicklung, warum so was nicht immer einfach ist.
Für 4.9 habe ich die Theme-Engine Aurorae in QML neugeschrieben, mit dem Ergebniss, dass sie stabiler ist und deutlich performanter (schlägt bei meinen bisherigen Tests das native Standardtheme Oxygen).
Also klare Verbesserungen. Nur gibt es auch eine Regression: Window Tabs funktionieren nicht mehr. Was soll ich nun machen, falls ich nicht die Zeit finde das bis zum Release wieder zu implementieren? Ich bin auf deine Meinung gespannt.
Mögliche Optionen:
Revert auf Aurorae aus 4.8
Aufhalten des kompletten KDE SC Release bis ich es endlich implementiert habe
Plasma Workspaces werden in 4.9 nicht released bis ich es endlich implementiert habe
KWin wird nicht in 4.9 released bis ich es endlich implementiert habe
Nun denn, schauen wir uns die Optionen im Einzelnen an und denken dabei auch daran, dass es hier um ein optionales Feature in einem optionalen Feature geht.
Ich liefere lieber eine Regression aus als eine wissentlich instabile Komponente, die ich neu geschrieben habe um die Crashes zu beheben.
Nicht verhältnissmäßig, ist ja nur ein optionales Feature in einem optionalen Feature
Ebenfalls nicht verhältnissmäßig, warum sollte man allen Plasma Anwendern das Update verweigern, nur weil ich das nicht hinbekomme?
Nicht möglich, KWin ist in einem Quellcodepaket zusammen mit anderen Komponenten aus Workspace. Das Verhalten des Workspaces mit KWin aus 4.8 ist ungetestet, vielleicht nicht mal möglich.
Wir sehen also, in der Theorie klingt sowas ganz toll, die Realität sieht aber anders aus. Und das ist nun ein Fall wo uns die Regression lange vorher bekannt ist und nicht wo wir sie vielleicht zwei Wochen vor dem Release erfahren und der zuständige Entwickler gerade im Urlaub ist, auf Klausuren lernt oder aus anderen Gründen keine Zeit hat.
Von Frustrierter KDE User am Mo, 7. Mai 2012 um 21:33 #
Keine Ahnung was Window Tabs sind und wie viele Leute das betrifft aber ich würde trotzdem Option 1 nehmen.
Das ist doch genau dieses "Auf und Ab" was hier schon kritisiert wurde. Bei jedem Update fragt man sich als User doch nur noch was diesmal wieder nicht mehr geht. Mit den aktuellen Bugs hat man sich in der Regel schon arrangiert. Man weiß woran man ist und kennt in den meisten Fällen einen Workaround.
Wenn man sich wenigstens darauf "verlassen" könnte (klar, geht nicht immer), dass die alten Sachen nach einem Update noch laufen, dann wäre die längere Wartezeit bis zum Fix zu verschmerzen. Bei den aktuellen Updates betet man einfach, dass diesmal nichts kaputt gegangen ist auf das man angewiesen ist.
Aber du als KWin-Entwickler bist da eh ein schlechtes Beispiel. KWin ist mir schon lange nicht mehr abgestürzt und ich kenne eigentlich auch sonst keinen der sich über KWin beschwert. Auch sind die Foren nicht voll von Leuten, die über KWin-Probleme berichten.
Deine Kollegen von der Nepomuk-, Akonadi- und KMail-Fraktion sollten sich eher angesprochen fühlen.
Keine Ahnung was Window Tabs sind und wie viele Leute das betrifft aber ich würde trotzdem Option 1 nehmen.
Dann kommt jetzt aber noch ein anderes Problem. Nachdem ich Aurorae ohne Tabs neugeschrieben hatte, wurde das Window Tabbing komplett neu implementiert um Stabilitätsprobleme zu beheben mit einem API Bruch. Die einzige Fensterdeko, welche es unterstützt (Oxygen) wurde angepasst.
Heißt ein Revert ist nicht mehr möglich, da der Quellcode nicht kompilieren würde.
Soll nun auch das reverted werden und bekannte Crashes wieder eingeführt werden, obwohl sie behoben sind?
Und was dann? Gibt es nicht vielleicht weitere Komponenten innerhalb KWins, die auf der neuen Tabbing API aufbauen (ja gibt es), müsste man dann das auch zurück spielen? Auf was läuft es hinaus: alles zurück.
Wie ich hier gerade hoffentlich erklären kann, ist zurück in der Realität meistens nicht mehr machbar. Irgendwann ist der Punkt of no return erreicht ab dem ein zurück mehr Probleme verursacht als ein weiter mit bekannten Regressionen.
Für 4.9 habe ich die Theme-Engine Aurorae in QML neugeschrieben, mit dem Ergebniss, dass sie stabiler ist und deutlich performanter (schlägt bei meinen bisherigen Tests das native Standardtheme Oxygen).
Also klare Verbesserungen. Nur gibt es auch eine Regression: Window Tabs funktionieren nicht mehr. Was soll ich nun machen, falls ich nicht die Zeit finde das bis zum Release wieder zu implementieren? Ich bin auf deine Meinung gespannt.
Mögliche Optionen:
Nun denn, schauen wir uns die Optionen im Einzelnen an und denken dabei auch daran, dass es hier um ein optionales Feature in einem optionalen Feature geht.
Wir sehen also, in der Theorie klingt sowas ganz toll, die Realität sieht aber anders aus. Und das ist nun ein Fall wo uns die Regression lange vorher bekannt ist und nicht wo wir sie vielleicht zwei Wochen vor dem Release erfahren und der zuständige Entwickler gerade im Urlaub ist, auf Klausuren lernt oder aus anderen Gründen keine Zeit hat.
Keine Ahnung was Window Tabs sind und wie viele Leute das betrifft aber ich würde trotzdem Option 1 nehmen.
Das ist doch genau dieses "Auf und Ab" was hier schon kritisiert wurde. Bei jedem Update fragt man sich als User doch nur noch was diesmal wieder nicht mehr geht. Mit den aktuellen Bugs hat man sich in der Regel schon arrangiert. Man weiß woran man ist und kennt in den meisten Fällen einen Workaround.
Wenn man sich wenigstens darauf "verlassen" könnte (klar, geht nicht immer), dass die alten Sachen nach einem Update noch laufen, dann wäre die längere Wartezeit bis zum Fix zu verschmerzen. Bei den aktuellen Updates betet man einfach, dass diesmal nichts kaputt gegangen ist auf das man angewiesen ist.
Aber du als KWin-Entwickler bist da eh ein schlechtes Beispiel. KWin ist mir schon lange nicht mehr abgestürzt und ich kenne eigentlich auch sonst keinen der sich über KWin beschwert. Auch sind die Foren nicht voll von Leuten, die über KWin-Probleme berichten.
Deine Kollegen von der Nepomuk-, Akonadi- und KMail-Fraktion sollten sich eher angesprochen fühlen.
Heißt ein Revert ist nicht mehr möglich, da der Quellcode nicht kompilieren würde.
Soll nun auch das reverted werden und bekannte Crashes wieder eingeführt werden, obwohl sie behoben sind?
Und was dann? Gibt es nicht vielleicht weitere Komponenten innerhalb KWins, die auf der neuen Tabbing API aufbauen (ja gibt es), müsste man dann das auch zurück spielen? Auf was läuft es hinaus: alles zurück.
Wie ich hier gerade hoffentlich erklären kann, ist zurück in der Realität meistens nicht mehr machbar. Irgendwann ist der Punkt of no return erreicht ab dem ein zurück mehr Probleme verursacht als ein weiter mit bekannten Regressionen.