Login


 
Newsletter
Werbung

Thema: KDE 4.8.3 freigegeben

47 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von gol am Fr, 4. Mai 2012 um 08:41 #

Ist denn schon abzusehen, wie lange noch die 4er Serie Unterstützung erhält?

  • 0
    Von hjb am Fr, 4. Mai 2012 um 09:25 #

    Mindestens fünf Jahre, siehe Kubuntu 12.04 LTS.

    Es wird aber nach meinem Verständnis keine große Rolle spielen, da es kein KDE 5 geben soll. Es hieß ja, dass die Bibliotheken zu KDE Frameworks 5 umgebaut werden, die aber zu den Applikationen kompatibel bleiben. Vielleicht heißt das auch nur, dass sie mit den KDE4-Bibliotheken koexistieren. Mal abwarten.

    • 0
      Von mgraesslin am Fr, 4. Mai 2012 um 12:09 #

      Mal abwarten.
      Die beste Zusammenfassung die es dafür gibt. Aktuell gibt es noch keine Planungen zu einem "KDE 5", daher kann man ja auch nicht wissen wie lange die "4.x" Serie unterstützt wird.

      Ich persönlich sehe keinen Grund die 4 durch eine 5 bei den Anwendungen und Workspaces zu ersetzen nur weil Qt 5 und Frameworks 5 verwendet werden.

0
Von Bolitho am Fr, 4. Mai 2012 um 13:22 #

Danke für gute Arbeit in Sachen Produktpflege :-) Da viele "User" hier immer die Fehler von KDE anprangern und den Entwicklern vorwerfen, dass sie am Bug-Fixing einfach keinen Spaß haben, will ich hier mal explizit "Danke" für diese Arbeit sagen! Die monatlichen Fixes sind imho wirklich sinnvoll und zeigen allen Spöttern, dass das KDE Projekt Fehler durchaus ernst nimmt.

  • 0
    Von JoJo am Fr, 4. Mai 2012 um 16:30 #

    Dann sollen sie mal ganz schnell die Taskbar fixen. Da werden ständig Icons übereinander dargestellt, so dass man nur noch mit Alt-Tab umschalten kann.

    Solche peinlichen Fehler gabs noch nicht mal bei Windows 95. Bei KDE habe ich diesen Fehler jetzt schon seit Ewigkeiten (auf mehreren, unterschiedlichen Rechnern).

    • 0
      Von OjOj am Fr, 4. Mai 2012 um 17:16 #

      Hab ich schon sporadisch gehabt, aber schon ewig nicht gesehen. Muß sich wohl um ne ältere Version handeln. Bitte eine aktuelle Version als Argumentationsgrundlage verwenden, oder in einer entsprechend älteren Releaseankündigung posten.

      • 0
        Von JoJo am Fr, 4. Mai 2012 um 17:49 #

        Ja, ganz alte Version, schon einen ganzen Monat alt: 4.8.2.

        Den Bug gibt es schon seit über einem Jahr und ich bezweifle, dass er in 4.8.3 gefixt wurde.

        Soviel zum Thema, dass KDE Entwickler die Bugs ernst nehmen.

        • 0
          Von mgraesslin am Sa, 5. Mai 2012 um 09:45 #

          Ist doch alles dokumentiert. Zweiter Kommentar hier: http://kdenews.org/2011/12/22/kde-makes-first-48-release-candidate-available-adds-secret-service

          Wenn du irgendwelche weiteren Ideen hast wie man das Problem beheben kann (viel wichtiger wäre überhaupt erst mal einen sicheren Weg zu finden es zu reproduzieren), sind die KDE Entwickler bestimmt sehr interessiert daran deine Ideen kennen zu lernen.

          • 0
            Von JoJo am Sa, 5. Mai 2012 um 13:14 #

            Das Problem welches dort beschrieben ist, habe ich aber nicht. Dass geschlossene Fenster in der Taskleiste verweilen hatte ich erst ein oder zwei mal.

            Bei mir überlappen sich ständig die Icons von geöffneten Programmen. Die Taskleiste kennt die Icons also, ist aber nicht in der Lage sie korrekt zu gruppieren und aufzureihen. Daher glaube ich auch nicht, dass irgendwelche Events von anderen Plasma-Widgets verschluckt werden. Die Taskleiste hat alle Informationen die sie braucht um ihren Job korrekt auszuführen, versagt dann aber kläglich.

            Die Berechnung der korrekten Position geht aber noch nichtmal mit einem einzigen Fenster richtig. Wenn man nur ein Programm geöffnet hat, dann passiert es ebenfalls ständig, dass das Fenster-Symbol in der Mitte der Taskleiste dargestellt wird. Das stört nicht weiter, weil die Basisfunktionalität ja noch gegeben ist, hinterlässt aber einen eindeutigen Eindruck über den zugrundeliegenden Code. Wenn es noch nichtmal mit einem Icon korrekt klappt, wer kann dann erwarten, dass es mit 10 Icons vernünftig funktioniert?

            In der Fülle der Bugs, die KDE hat mögen solche Issues als Minor eingestuft werden. Dennoch sind es gerade diese Bugs, die den bleibenden Eindruck hinterlassen. Die Taskleiste ist einfach eine zentrale Komponente von der man erwarten können sollte, dass sie einwandfrei funktioniert. Wenn diese absoluten Basics schon nicht gehen, wer will sich denn dann ernsthaft mit dem Rest rumärgern.

            • 0
              Von meh am Mo, 7. Mai 2012 um 14:33 #

              hab ich noch nie gesehen, unter keiner von mir benutzten distribution. ist der fehler lokal? vielleicht sind aus irgendeinem alte configfiles übriggeblieben/draufkopiert, die das problem auslösen. probier mal eine frische config, unter einem neuen useraccount etwa. würde mich nicht wundern, wenn da alles in ordnung ist.

              • 0
                Von JoJo am Mo, 7. Mai 2012 um 19:43 #

                hab ich noch nie gesehen, unter keiner von mir benutzten distribution. ist der fehler lokal? vielleicht sind aus irgendeinem alte configfiles übriggeblieben/draufkopiert, die das problem auslösen. probier mal eine frische config, unter einem neuen useraccount etwa. würde mich nicht wundern, wenn da alles in ordnung ist.

                Haha, das finde ich jetzt wirklich witzig, denn ich habe gerade den Post von Marting Grässlin weiter unten hier im Forum gelesen. Da schreibt er:

                In der ganzen Zeit seit ich bei KDE mitarbeite, habe ich keinen einzigen Bug Report gesehen, wo ein Nutzer sagt, das ein Konfigurationsupdate nicht funktioniert hat.

                Da habe ich und offensichtlich auch du lieber meh ganz andere Erfahrungen gemacht. In diesem Fall hat das Löschen der Konfiguration aber nichts gebracht. Der Fehler ist aber bekannt und auch irgendwo auf bugs.kde.org zu finden.

                • 0
                  Von mgraesslin am Mo, 7. Mai 2012 um 19:56 #

                  Der Fehler ist aber bekannt und auch irgendwo auf bugs.kde.org zu finden
                  -> Bug 224447

                  Übrigens ist es nach Meinung des Maintainers doch ein und der selbe Bug wie die Ghost Entries.

                  • 0
                    Von JoJo am Mo, 7. Mai 2012 um 20:17 #


                    Gemeldet am: 27.01.2010

                    Das sagt doch schon alles.

                    • 0
                      Von mgraesslin am Mo, 7. Mai 2012 um 20:38 #

                      und was sagt es denn?

                      Mir sagt das nur, dass der Bug nicht identifiziert werden kann und schwer zu beheben ist. Siehe dazu auch den Kommentar auf kdenews, den ich in dem Thread hier schon verlinkt hatte.

                      Wenn du irgendwelche neue Erkenntnisse hast, wie der Bug reproduziert werden kann, sind dir sicherlich alle über dein Wissen dankbar. Leider kann man nicht reproduzierbare Bugs nicht beheben und wie ich in Kommentar #15 schrieb, konnte ich den Bug nie reproduzieren (tritt aber bei mir auch überhaupt nicht mehr auf).

                      • 0
                        Von JoJo am Mo, 7. Mai 2012 um 21:02 #

                        Wenn du irgendwelche neue Erkenntnisse hast, wie der Bug reproduziert werden kann, sind dir sicherlich alle über dein Wissen dankbar.

                        Das geht ganz einfach:

                        * Kubuntu 11.10 bzw 12.04 installieren.
                        * KDE 4.7.4 (bei 11.10) oder KDE 4.8.3 (bei 12.04) installieren
                        * Neues Panel am oberen Bildschirmrand erstellen und auf "automatisch ausblenden" einstellen.
                        * Taskleiste in das Panel packen
                        * Systemabschnitt der Kontrollleiste reinpacken

                        => Problem tritt alle paar Minuten bei mir auf und das auf drei völlig unterschiedlichen Rechnern

                        • 0
                          Von mgraesslin am Mo, 7. Mai 2012 um 21:19 #

                          Mit der Aussage "tritt alle paar Minuten bei mir auf" ist das leider keine Anleitung um das Problem zu reproduzieren. Es ist immer noch die große Unbekannte des "warum", denn aus eigener Erfahrung kann ich sagen, dass es nichts mit dem automatischen ausblenden zu tun hat.

                          Zurück auf Los, wir sind genau so klug wie vorher.

                          • 0
                            Von JoJo am Mo, 7. Mai 2012 um 22:05 #

                            Zurück auf Los, wir sind genau so klug wie vorher.

                            Wenn es alle paar Minuten auftritt, dann sollte es ja wohl debugbar sein. Das mag zwar aufwendig sein aber sicher nicht unmöglich.

                            Irgendwie werden die Berechnungen zur Platzierung der Icons ja durchgeführt. Wenn man also alle Eingangsparameter und alle Ausgangsparameter pedantisch mitloggt, dann sollte es ja wohl ersichtlich werden in welchem Codeabschnitt die Berechnung schief geht.

                            • 0
                              Von mgraesslin am Mo, 7. Mai 2012 um 23:17 #

                              Nein, leider nicht. In diesem Fall ist ja bereits bekannt, dass irgendwie X im Spiel ist. Heißt wir verwenden ein Protokoll im Zusammenspiel mit mehreren Anwendungen. Im konkreten Fall vermutlich vier Anwendungen:


                              • X Server

                              • Fenstermanager

                              • Desktop Shell

                              • und die Anwendung selbst zu der das Fenster gehört

                              Greift man nun durch logging oder noch schlimmer debugging Mechanismen ein, verändert man natürlich den Protokollfluss. Der Fehler tritt im schlimmsten Fall überhaupt nicht mehr auf.

                              Eine solche Situation bezeichnet man auch als Heisenbug.

                        0
                        Von JoJo am Mo, 7. Mai 2012 um 21:11 #

                        Btw, wo du doch immer so schön sagst es gäbe keine Probleme mit den alten Konfigdateien. Hier ein aktuelles Beispiel:

                        Gerade eben Kubuntu 11.10 auf 12.04 mit KDE 4.8.2 aktualisiert. In der Favoritenleisten des K-Menüs war ein Eintrag auf Libreoffice. Der ist zwar noch da, wird aber ohne Icon dargestellt. Jetzt wollte ich ihn entfernen und aus den Programmen heraus wieder neu anlegen lassen. Der Eintrag wird aber vom Favoritenmenü nicht erkannt. Er ist zwar in dem Favoritenmenü, wenn ich aber mit der rechten Maustaste draufklicke um ihn zu entfernen erscheint da nur "Zu Favoriten hinzufügen", nicht aber "Aus Favoriten entfernen" wie bei den anderen Einträgen.

                        Wir haben hier also einen Favoriteneintrag der von seinem eigenen Favoritenmenü nicht mehr als Favorit erkannt wird, aber trotzdem noch angezeigt wird. Das nur als Beispiel für ein Problem, wo das Löschen der Konfiguration hilft. Als User muss man jetzt abwägen ob es länger dauert im Google herauszufinden welche Datei man bearbeiten/löschen muss oder ob es schneller geht einfach die komplette Konfig zu löschen.

                        Wo werden denn die Favoriten gespeichert?


                        • 0
                          Von mgraesslin am Mo, 7. Mai 2012 um 21:21 #

                          Btw, wo du doch immer so schön sagst es gäbe keine Probleme mit den alten Konfigdateien
                          Ich habe nirgends geschrieben, dass es keine Probleme mit alten Konfigurationsdateien gäbe. Bitte ließ dir noch mal durch was ich geschrieben habe und verallgemeinere nicht.

                          LibreOffice ist übrigens kein Favorit der von KDE gesetzt wird, sondern ein Favorit der vermutlich von der Distribution gesetzt wird. Daher wende dich doch bitte an die Distribution deines Vertrauens :-)

                          • 0
                            Von JoJo am Mo, 7. Mai 2012 um 21:57 #

                            Ich habe nirgends geschrieben, dass es keine Probleme mit alten Konfigurationsdateien gäbe. Bitte ließ dir noch mal durch was ich geschrieben habe und verallgemeinere nicht.

                            Gut, du hast geschrieben, dass dir kein einziger Bug-Report bekannt ist. Dann gab es da aber auch noch die Riesendiskussion mit "Frustrierte KDE User" bei der letzten Release-Ankündigung: http://www.pro-linux.de/news/1/18235/comm/510206/re2-kein-grund-zum-freuen-.html

                            LibreOffice ist übrigens kein Favorit der von KDE gesetzt wird, sondern ein Favorit der vermutlich von der Distribution gesetzt wird. Daher wende dich doch bitte an die Distribution deines Vertrauens

                            Oh man, den LibreOffice-Favorit habe ICH gesetzt - VOR dem Update und jetzt wird er nicht mehr als Favorit erkannt und ich kann ihn nicht entfernen.

                            • 0
                              Von mgraesslin am Mo, 7. Mai 2012 um 23:20 #

                              Oh man, den LibreOffice-Favorit habe ICH gesetzt - VOR dem Update und jetzt wird er nicht mehr als Favorit erkannt und ich kann ihn nicht entfernen.
                              Das klingt dann tatsächlich nach einem Bug, der überhaupt nichts mit der Konfiguration zu tun hat. Entsprechende Komponenten wurden meines Wissens nach nicht angefasst.

0
Von lumnis am Sa, 5. Mai 2012 um 23:43 #

Wollte eigentlich gern wieder zurück zu Kontakt/KMail da u.a. die 3 Spaltenansicht von Thunderbird mir nicht gefällt, doch wenn der Inhalt von eingehenden eMails gelöscht wird, geht das einfach nicht. Bug ist seit Längerem bekannt und offensichtlich auch nicht im neuen release gefixt.

0
Von Idiotenpfleger am So, 6. Mai 2012 um 08:29 #

In der Reihe der Versionen war es bei mir persönlich so, dass KDE 4.3 bis 4.5 richtig gut funktionierten, während 4.6 den Anfang der Talfahrt markierte und 4.7 einen üblen Tiefpunkt darstellte. KDE 4.8.x macht derzeit wieder einen guten Eindruck (mit Ausnahme von KDEPIM, mit dem ich aber komplett abgeschlossen habe = es aufgegeben habe).

Man befindet sich also auf einer qualitätsmäßigen Berg- und Talfahrt.

Das resultiert bei Anwendern wie mir in einer komischen ängstlichen Erwartung... wird die nächste Version wieder ein Erfolg oder doch wieder ein Desaster? Blöd dabei ist auch (für den unbegabten Anwender) dass man sich nicht auf die Kommentare im Netz verlassen kann. Denn es gab massenhaft Lob über 4.7, das meiner Meinung nach absolut nicht gerechtfertigt war. Andererseits gibt es massenhaft Kritik über Versionen, die gut laufen/liefen, wo die Kritik ebenfalls nicht gerechtfertigt ist...
Somit kann man schlecht herausfiltern, welche KDE-Version man nutzen kann und um welche man besser einen Bogen macht.

Wenn man sich wenigstens auf die Qualitätssicherung von KDE selbst verlassen könnte... kann man aber nicht.
Die Tatsache, dass das immer ein Risikospiel bleiben wird, ist sehr schade, denn KDE ist grundsätzlich eine gute DE und hat es eigentlich nicht verdient, dass man sich als Anwender darüber ärgert, auf die neueste Version aktualisiert zu haben...

Mehr Qualitätssicherung wäre toll. Das heißt nicht unbedingt Bugfixen, Bugfixen... sondern sicherstellen, dass die neuere Version auf keinen Fall schlechter läuft, als die vorhergehende. Damit dieses Auf-und-ab aufhört.

  • 0
    Von Frustrierter KDE User am So, 6. Mai 2012 um 12:34 #

    Mehr Qualitätssicherung wäre toll. Das heißt nicht unbedingt Bugfixen, Bugfixen... sondern sicherstellen, dass die neuere Version auf keinen Fall schlechter läuft, als die vorhergehende.

    Das mit der Qualitätssicherung und den Regressionen habe ich auch schon bemängelt. Mir wurde dann hier im Forum von Martin Gräßlin erklärt, dass das nie passieren wird. Es wird keine zentrale Instanz, ähnlich Linus Torvalds beim Kernel, geben, da KDE nur ein loser Zusammenschluss von Entwicklern ist. Im Klartext: Jeder frickelt so vor sich hin und schiebt dann der Release Crew den Code rüber. Die Release Crew packt dann nur noch zusammen, egal in welchem Zustand das Zeug gerade ist.

    Somit hängt es von den einzelnen Entwicklern ab, wie hoch deren Qualitätsstandards sind. KWin läuft zum Beispiel recht stabil, wogegen KDEPIM, naja du weißt ja selber...

    • 0
      Von Idiotenpfleger am So, 6. Mai 2012 um 22:20 #

      das habe ich mir eigentlich schon denken können...

      Wenn gesagt wird, dass KDE nur ein loser Zusammenschluß ist usw. , dann wirkt es schon eigenartig, wenn KDE als Trademark verwendet wird. Denn dies suggeriert, dass KDE nicht nur ein loser Zusammenschluß von Leuten ist, die einem Release-Team ihren Krempel vorwerfen...

      wie gesagt: eigenartig und schade, denn grundsätzlich hat das Produkt so etwas nicht verdient.

      • 0
        Von krake am Mo, 7. Mai 2012 um 10:55 #

        Wenn gesagt wird, dass KDE nur ein loser Zusammenschluß ist usw. , dann wirkt es schon eigenartig, wenn KDE als Trademark verwendet wird.

        Es hilft dem Verständnis normalerweise wenn man berücksichtig dass KDE eine Organisation ist die viele einzelne Produkte herstellt, ähnlich wie große Softwarehersteller oder z.B. Apache.

        Jedes Produkt hat wie z.B. der Linuxkernel einen Maintainer, der durchaus auch Entwicklungsprozeduren vorgeben kann.
        Wenn Martin als KWin Maintainer sich dazu entscheidet ab eine bestimmten Zeitpunkt mit einem Stagingbranch zu arbeiten, bin ich mir sicher dass das von allen KWin Entwicklern auch entsprechend umgesetzt wird.

        Das ist möglicherweise auch auf Produktgruppen anwendbar, entweder in dem man sich auf einen Gruppenmaintainer einigen kann, oder indem sich die Produktmaintainer einen speziellen Zusammenarbeitsmechanismus vereinbaren.

        Das ist natürlich schon einiges schwieriger, vorallem auch weil es dafür keine (oder sehr wenige) entsprechenden Vorbilder gibt.

        0
        Von mgraesslin am Mo, 7. Mai 2012 um 19:26 #

        Das klingt ja jetzt so als ob wir alle nicht miteinander sprechen würden und hier werden Sachen zusammengewürfelt wie Trademark was überhaupt nichts miteinander zu tun hat.

        Die KDE Community bietet sehr vielfältige Software an, wie zum Beispiel einen Fenstermanager und einen Emailclient. Das ist so verschieden, dass ich als KWin Entwickler nicht bei KMail mitarbeiten kann (bisher ein Commit in kdepimlibs) und z.B. Kevin nicht bei KWin mitarbeiten kann (aktuell 0 Commits in KWin).

        So gesehen ist das dann nur ein "loser Zusammenschluss", nichts desto trotz einigen uns viele Sachen als Community und in der Software. KMail und KWin haben zum Beispiel sehr ähnliche Abhängigkeiten: Qt, KDElibs, D-Bus, sind GPL lizensiert, sind ähnlich alt (KMail ist eine der wenigen KDE Anwendungen die älter ist als KWin), starten beide mit einem großen K im Namen usw. Daher ist es auch klar, dass sie unter das gleiche Trademark fallen.

        Solch vielfältige Software hat natürlich auch Auswirkungen auf den Releaseprozess. Man muss sich schon fragen wie viel das Releasekriterium von KWin mit dem Releasekriterium von KMail zu tun hat. Ist ein Crash in KWin in Zusammenspiel mit einer alten Grafikkarte für KWin ein Grund das Release zu verschieben? Ist dies auch ein Grund das Release von KMail zu verschieben? Oder auf der anderen Seite ist ein Bug, der zu Datenverlust unter Microsoft Windows führt Grund genug das Release von KWin zu verschieben, obwohl es nicht auf dieser Plattform veröffentlicht wird? Insbesondere wenn man betrachtet, dass die KWin Entwickler keine Möglichkeit haben die Probleme zu beheben, welche ihr Release gerade verschiebt?

        Natürlich ist so eine Abwägung nicht möglich. Weder für mich, noch für irgendjemand anderes in der KDE Community. Somit auch nicht für das Release Team. Jemand der vom Release Team erwartet, dass er Qualitätschecks für alle KDE Software einfordert, verkennt einfach die tatsächlichen Gegebenheiten. Dies ist nicht die Aufgabe, die das Release Team von der Community bekommen hat und soweit ich das sehe, sieht sich das Release Team auch nicht in dieser Rolle. Seine Aufgabe ist es ein Release durchzuführen - kann jede Anwendung auch selbst machen und gibt genügend, die das machen (Calligra, Amarok, Digikam um nur mal ein paar zu nennen).

        • 0
          Von Frustrierter KDE User am Mo, 7. Mai 2012 um 19:55 #

          Natürlich ist so eine Abwägung nicht möglich. Weder für mich, noch für irgendjemand anderes in der KDE Community.

          Die Abwägung ist nicht möglich? Warum nur habe ich solch eine Antwort von einem KDE Entwickler erwartet?

          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.

          Das mag man nicht immer einhalten können, aber diese einfache Regel hätte einige katastrophale Releases der letzten Jahre vermieden.

          • 0
            Von HawkBln am Mo, 7. Mai 2012 um 20:14 #

            "Warum nur habe ich solch eine Antwort von einem KDE Entwickler erwartet?"

            Eventuell, weil du ohnehin als frustrierter KDE User objektiven Argumenten nicht mehr aufgeschlossen gegenüber stehst. Im Prinzip ist es zwecklos, dir etwas zu erklären. Du glaubst nur noch, was dir genehm ist. Sorry.

            "Ziel sollte es sein keine Regressionen zu haben."

            Ich denke, das sehen die Entwickler auch so. Ich habe erhebliche Zweifel, dass sie dir Regressionen absichtlich unterschieben.

            "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."

            Das setzt voraus, dass der Fehler in dieser Komponente überhaupt bekannt ist. Was offenbar nicht immer der Fall ist. Und sollte er bekannt sein, stellt sich die Frage, ob es ein Fehler ist, der alle User trifft und damit ein echter Release-Stopper ist oder, ob er nur in einem von 1000 Fällen und unter sehr speziellen Bedingungen auftritt. Dann muss abgewogen werden. Und unter Umständen wird dennoch ein Release erfolgen und erst in einer der nächsten Versionen der Fehler behoben.

            • 0
              Von Frustrierter KDE User am Mo, 7. Mai 2012 um 20:38 #

              Eventuell, weil du ohnehin als frustrierter KDE User objektiven Argumenten nicht mehr aufgeschlossen gegenüber stehst. Im Prinzip ist es zwecklos, dir etwas zu erklären. Du glaubst nur noch, was dir genehm ist. Sorry.

              Leidest du an Realitätsverlust, schau dir doch mal euren Bugtracker an? Oft genug werden die Bugs noch während der Beta- oder RC-Phase eingetragen und es wird dann trotzdem released, siehe weiter unten.


              "Ziel sollte es sein keine Regressionen zu haben."

              Ich denke, das sehen die Entwickler auch so. Ich habe erhebliche Zweifel, dass sie dir Regressionen absichtlich unterschieben.

              Und ich habe erhebliche Zweifel daran, dass sie es nicht tun. Anders kann man die vielen katastrophalen Releases der letzten Jahre nicht erklären:

              * Von den Versionen vor 4.3 brauchen wir gar nicht erst reden.
              * Umstellung des Adressbuches auf Akonadi.
              * Akonadi und Nepomuk an sich.
              * Umstellung von Dolphin auf Nepomuk
              * KDEPIM2

              Diese ganzen Komponenten hätten in ihren Ursprungsfassungen nie released werden dürfen. Die Bugtracker waren voll von Bugs, die noch während der Beta- und RC-Phase entdeckt wurden. Trotzdem wurde der Mist an den User weitergegeben!

              Das setzt voraus, dass der Fehler in dieser Komponente überhaupt bekannt ist.

              Und das ist auch Ok. Wenn ein Fehler erst nach der Release in den Bugtracker eingetragen wird, dann wurde er halt übersehen.

              Und sollte er bekannt sein, stellt sich die Frage, ob es ein Fehler ist, der alle User trifft und damit ein echter Release-Stopper ist oder, ob er nur in einem von 1000 Fällen und unter sehr speziellen Bedingungen auftritt. Dann muss abgewogen werden. Und unter Umständen wird dennoch ein Release erfolgen und erst in einer der nächsten Versionen der Fehler behoben.

              Ja, die Frage stellt sich. Die Vergangenheit von KDE hat aber gezeigt, dass nur all zu oft Komponenten released werden, die man bestenfalls als Alpha-Version bezeichnen kann. Das muss nicht sein!

              • 0
                Von HawkBln am Mo, 7. Mai 2012 um 21:18 #

                Ich verwende KDE schon seit Version 0.9 (das ist jetzt 14 Jahre her). Ich habe also schon ziemlich alles mitgemacht, was KDE zu bieten hatte. Dennoch bin ich mit der aktuellen Version höchst zufrieden.

                Das viele User mit Akonadi und Nepomuk nichts anfangen können, kann ich persönlich akzeptieren, aber nicht nachvollziehen. Ich finde es eine großartige Idee. Und seit dem Release 4.8.2 "frisst" auch virtuoso keine Rechenleistung mehr. Beides funktioniert mittlerweile anstandslos. Auch in Zusammenarbeit mit KDEPIM2. Ich verwende es mit 3 IMAP-Accounts und synchronisiere mit einem Google-Account Kalender, Aufgaben sowie Kontakte. Ohne Probleme.

                Ja, es gab Fehler. Die gab es in den letzten 14 Jahren regelmäßig. Aber wenn man die neuen Ideen gleich begraben hätte, weil es etwas schwierig geworden ist, dann wäre KDE nicht da, wo es jetzt ist.

                • 0
                  Von Frustrierter KDE User am Mo, 7. Mai 2012 um 21:42 #

                  Wer redet hier denn von Ideen begraben?

                  Ich habe nichts gegen Akonadi und Nepomuk, abgesehen davon, dass sie viel zu früh released wurden. Monatelang durfte man sich bei jedem einloggen irgendwelche wirren Akonadi-Fehlermeldungen ansehen, die weder verständlich noch sonderlich hilfreich waren.

                  Nepomuk hat monatelang auch den performantesten Rechner platt gemacht und Kmail2 hat E-Mails verschluckt oder tausendfach dupliziert.

                  Diese Probleme waren alle zum Release der Komponenten bekannt.

                  Nach der katastrophalen Release von 4.0, hieß es ganz groß, dass dies eine einmalige Sache war, da man unbedingt mal ein KDE4 releasen musste damit die Entwicklung in Fahrt kommt. Wie sich gezeigt hat, war das keine einmalige Ausnahme, sondern wurde zur Regel mit jeder weiteren, größeren Komponente, die hinzugefügt wurde.

                  • 0
                    Von kotz am Sa, 12. Mai 2012 um 14:32 #

                    Bezeichnend dabei ist, dass selbst die Suse-KDE-Cracks KDEPIM2/Akonadi in openSUSE 12.1 nicht mehr hinbiegen konnten. Als ein Suse-Entwickler konsterniert die Bugs auf der Mailingliste zur Diskussion stellte, kam dann zum Abschluss ein eher fassungloses "Any Suggestions?"
                    openSUSE hätte liebend gerne noch einmal das alte KMail aus KDE 4.4 verwendet, aber das klappte dämlicherweise nicht trotz angeblicher Rückwärtskompatibilität der neuen kdepim-Libs.
                    Der Vorschlag, nicht alles das, was Upstream openSUSE in einem sichtlich unausgegorenen Zustand vor die Füße wirft, auch aufzuheben und zu veröffentlichen, wurde leider verworfen.

            0
            Von mgraesslin am Mo, 7. Mai 2012 um 20:55 #

            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:


            1. Revert auf Aurorae aus 4.8

            2. Aufhalten des kompletten KDE SC Release bis ich es endlich implementiert habe

            3. Plasma Workspaces werden in 4.9 nicht released bis ich es endlich implementiert habe

            4. 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.


            1. Ich liefere lieber eine Regression aus als eine wissentlich instabile Komponente, die ich neu geschrieben habe um die Crashes zu beheben.

            2. Nicht verhältnissmäßig, ist ja nur ein optionales Feature in einem optionalen Feature

            3. Ebenfalls nicht verhältnissmäßig, warum sollte man allen Plasma Anwendern das Update verweigern, nur weil ich das nicht hinbekomme?

            4. 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.

            • 0
              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.

              • 0
                Von mgraesslin am Mo, 7. Mai 2012 um 23:27 #

                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.

    0
    Von kotz am So, 6. Mai 2012 um 16:49 #

    "mit Ausnahme von KDEPIM, mit dem ich aber komplett abgeschlossen habe = es aufgegeben habe"

    Ich warte da schon auf die erste Umfrage, in der eine Mainstreamdistro bei ihren Nutzern nachfragt, wer denn noch KDEPIM nutzt und ob man diese Software überhaupt noch anbieten sollte.

    • 0
      Von Idiotenpfleger am So, 6. Mai 2012 um 22:59 #

      für mich ist KDEPIM sowieso schon tot. Ich hoffe nur, dass die Situation mit den Paketabhängigkeiten so bleibt, dass man es auch zukünftig leicht deinstallieren kann. Würde ich eine Distro betreiben, würde ich mir den Traffic und den Platz im .iso eh sparen. Ganz ohne Umfrage.

    0
    Von Qualitätsbubi am So, 6. Mai 2012 um 18:58 #

    Es gibt ja noch was anderes und das ist die Konfiguration. Manchmal hilft es die Einstellungen vergangener Versionen zu löschen, und dann manuell wieder alles hinzubiegen. Wenn nach dem Update der Desktop zerschossen ist, dann ist das ein klarer Bug für mich. Die KDE Leute sollten mehr testen wie realexistierende Konfigurationen sich beim Upgrade zu einer neuen Version verhalten.

    • 0
      Von mgraesslin am So, 6. Mai 2012 um 19:33 #

      Die KDE Leute sollten mehr testen wie realexistierende Konfigurationen sich beim Upgrade zu einer neuen Version verhalten.
      In der ganzen Zeit seit ich bei KDE mitarbeite, habe ich keinen einzigen Bug Report gesehen, wo ein Nutzer sagt, das ein Konfigurationsupdate nicht funktioniert hat. Wird ein Fehler während der Betaphase gefunden, so ist das noch sehr leicht vor dem Release zu testen.

      Wenn wir aber keine Rückmeldungen in Form von Bugreports bekommen, dann muss doch alles super sein, oder?

      • 0
        Von kjkjkjkjkj am So, 6. Mai 2012 um 19:42 #

        Dein Vorposter meint vielleicht etwas Anderes:
        Wenn man früher z.B. KDE3-Versionen "upstream-natura" und dann solche mit SuSE-Extensions "hintereinander" installiert hatte (z.B. im Zuge des Wechsels zu Debians KDE3 und zurück), dann führte die jeweilige Benutzung der "falschen" .kde-Verzeichnisse im gleichen Home-Verzeichnis zu einem Kraut-und Rübendesktop (Fehlen von Kmenu u.ä.).
        Bevor man da überhaupt einen Bugreport annimmt, muß man genau fragen, was da an KDE unter welcher Distroversion auf welcher alten Konfiguration installiert wurde. Ein wirklicher Bug ist das IMO denn auch nicht.

        • 0
          Von Qualitätsbubi am So, 6. Mai 2012 um 21:27 #

          Naja, wenn Du Kubuntu upgradest und plötzlich dein KDE4 Panel verschwunden ist, dann wundert man sich schon. KDE hat auch keine "Reset" Funktionalität für ein "verstelltes" Panel. KDE checkt nicht, ob die aktuelle Konfiguration sinnvoll ist usw.

          • 0
            Von mgraesslin am So, 6. Mai 2012 um 21:40 #

            Das stimmt nicht. Plasma bietet an ein "Default Panel" zu erzeugen. Damit ist die Reset Funktionalität vorhanden.

            Was man hier nicht übersehen darf, ist dass Plasma ein komplett anderes Standardpanel ausliefert als die Distributionen. Ich möchte jetzt nicht Schuld auf die Distros abschieben, aber es macht den ganzen Prozess deutlich kompliziertes, da es den KDE Entwicklern eine Unbekannte gibt, die sie nicht berücksichtigen können. Wollte vor Kurzem mal Project Neon ausprobieren um mir einen aktuellen 4.9 Snapshot mit Default Optionen anzuschauen und das ging nicht, da Kubuntu andere default Optionen hat.

Pro-Linux
Frohe Weihnachten Fest!
Neue Nachrichten
Werbung