In diesem Fall war es kein harmloser Bug (es war nur noch 1 Programm über Task-Leiste erreichbar, alle anderen auf diese Weise nicht mehr), da muß man eben darauf warten bis dies gefixt wurde.
Das ganze erinnert mich an Xubuntu-LTS-10.04, da konnte der Xfce-Dateimanager keine Detailansicht darstellen(evtl Absturz), nur Icon-Ansicht. Grund war ein Bug in libgtk*xy, released wurde es trotzdem. Man musste einen anderen Dateimanager nehmen und 2 Monate warten bis das gefixt war. Zum vorzeigen war das nichts. Die Xfce-Leutchen konnten da nichts zu, aber der Nutzer macht da keinen Unterschied.
In diesem Fall war es kein harmloser Bug (es war nur noch 1 Programm über Task-Leiste erreichbar, alle anderen auf diese Weise nicht mehr), da muß man eben darauf warten bis dies gefixt wurde.
Dann erklär mir mal bitte wie man das machen soll. KDE hat ein Release mit keinen Problemen, dann veröffentlicht eine unserer Abhängigkeiten ein Release das ein Problem einführt - KDE Software nun kaputt und dann "warten bis diese gefixt wurde"? Was soll das bringen? Davon geht das Problem in der bereits veróffentlichten Version auch nicht weg.
Sorry aber die Welt ist nicht so einfach wie man sich das als Nutzer manchmal vorstellt.
Die meisten User interessiert es nicht wieso ein Bug da ist, was die sehen ist die Basiskomponente Task-Leiste die ein Arbeiten unmöglich macht(Programme verschwinden). Punkt. Und was die sehen ist: KDE
Bei meinem Xfce-Dateimanager-Beispiel reichte der angeführte Punkt für mich aus keine CDs mehr davon weiterzugeben.
Wie stellst du dir das nun vor, wie man solche Probleme erkennen und beheben soll?
Wenn 'ihr' auf externe Tools aufbaut dann seit ihr auch von denen abhängig. Entweder ihr nutzt Versionen wo bekannte Bugs nicht drin sind oder ihr meldet+wartet - oder ihr released trotz Bugs("sind nicht unsere Schuld")
Btw. der Fehler ist bei mir nur auf einem meiner drei Systeme aufgetreten und dort so selten, dass ich nie es reproduzieren konnte.
Tja, bei mir war es nach nach über 2 Jahren das erste mal wieder KDE, und eines der ersten Dinge die ich dort sah: Taskleisten-Bug.
Von ------------------------------ am Do, 28. Juni 2012 um 15:05 #
> Wenn 'ihr' auf externe Tools aufbaut dann seit ihr auch von denen abhängig. > Entweder ihr nutzt Versionen wo bekannte Bugs nicht drin sind
Das ist keine upstream/downstream Abhängigkeit sondern Aufgabe der Distributionen keine fehlerhaften Versionen auszuliefern oder schnellstmöglich zu aktualisieren.
Der downstream (KDE) *kann* nicht die Korrektheit des upstream (Abhängige Bibliothek) garantieren, weil er niemals die exakte Upstream Version kennt oder verantwortet. Demzufolge dürfte man niemals releasen, da es immer möglich ist eine fehlerhafte ältere oder neuere Version einer Abhängigkeit zu installieren.
Bestenfalls ist es möglich, bekannte generelle Schwächen im upstream (Treiber....) großräumig zu Umschiffen - allerdings auf Kosten von evtl. einwandfrei funktionierenden Features.
Linux ist nicht IOS und KDE nicht Apple wo alles zentral kontrolliert wird und Du nur installieren kannst, was Cupertino Dir erlaubt.
Wenn Du damit nicht klarkommst bist Du in dem Distributionsmodell falsch aufgehoben und suchst nach IOS oder evtl. auch Android. Schon bei Windows ist das (trotz signierter Treiber aber vor Metro) nicht mehr vollends gegeben.
Wenn bloß Deine Distro in dieser speziellen Hinsicht kontinuierlich Ärger macht, solltest Du überprüfen ob ihre Ziele mit Deinen Ansprüchen konform sind.
Bleeding edge am besten in rolling releases ist nicht für "einmal installieren und das läuft dann so die nächsten 5 Jahre" gedacht und LTS heißt auch nur "long time support" und nicht "ausgereift" (Ubuntu hat in 12.04 ein paar mächtige Klopper) - da die für Dich richtige Balance zwischen "neu" und "entgratet" zu finden ist allerdings allein Deine Aufgabe und die kann Dir auch beim besten Willen niemand abnehmen.
Wenn 'ihr' auf externe Tools aufbaut dann seit ihr auch von denen abhängig. Entweder ihr nutzt Versionen wo bekannte Bugs nicht drin sind oder ihr meldet+wartet - oder ihr released trotz Bugs("sind nicht unsere Schuld")
Willkommen in der Realität. Meine Komponente ist abhängig von den Grafikkarten Treibern. Nehmen wir mal das letzte Release. Wir hatten unser Release im Januar, heißt Feature Freeze war Oktober oder November. Verwendet wird die Version in den nächsten Distributionen, welche im April/Mai veröffentlichen.
Zum Zeitpunkt unserer Entwicklung war 7.11 die aktuelle Mesa Version, Mesa 8.0 wurde im Februar veröffentlicht - einen Monat nach unserem Release. Nun kombinieren Distributionen Mesa und KDE wie sie lustig sind.
Wir haben weder Möglichkeiten das zu testen noch irgendwelche darauf Einfluss zu nehmen. Wir sind da komplett abhängig von den Distributionen. Manche Distributionen haben dann noch so tolle Ideen wie llvmpipe zu aktivieren ohne mit uns Rücksprache zu halten, also wild an unserer Codebasis ohne Sinn und Verstand rumzupatchen.
Nun wie genau sollen wir also nur die Versionen verwenden wo Bugs nicht drinnen sind? Bzw. wie sollen wir überhaupt wissen, dass in der nächsten Version welche zum Zeitpunkt unseres Releases noch in Entwicklung ist, Probleme auftreten werden?
Ich bitte um konstruktive Vorschläge. Ich suche seit Jahren nach einer Lösung für dieses Problem
Indem man eine Art KDE-testsuite für Mesa schreibt, welche genau die Funktionen abbildet, die benötigt werden. Das hilft den Entwicklern der entsprechenden niederschichtigen Bibliotheken zu verstehen mit welchen Designentscheidungen sie Kompatibilität brechen, und es macht das Blama-Game einfach.
Danke, dass du dich bereiterklärst diese testsuite zu schreiben. Ist etwas was wir schon lange wollten und endlich möchte das jemand machen. Finde ich echt super von dir *thumbsup*
Das ist nicht ironisch gemeint, sondern ernst. Solche Sachen brauchen viel Zeit und wir können da jede Hilfe gebrauchen. Unser Blur Effekt ist übrigens Bestandteil der Piglit testsuite.
Du hast doch gefragt, was man nur tun könnte. Von den Leuten, die KDE kaputt gemacht haben, kann man auch erwarten es wieder zu flicken.
Gibt es denn bislang überhaupt eine KDE-Testsuite?
Wenn die Entwickler der Bibliotheken wie früher selbst KDE nutzen würden käme es ausserdem erst gar nicht zu dem Problem. Aber weil KDE unbenutzbar ist zum produktiven Arbeiten, benutzen es nur wenige Masochisten.
Ironischerweise wurde als KDE rauskam gesagt, dass KDE mit allen QT4-Versionen laufen soll. Prüft natürlich keiner.
Gibt es denn bislang überhaupt eine KDE-Testsuite?
Testsuite für was genau? KDE ist eine Community und kein Produkt. KDE entwickelt hunderte Produkte, da kann es nicht "eine" KDE-Testsuite geben. Also: was meinst du genau?
Wenn die Entwickler der Bibliotheken wie früher selbst KDE nutzen würden
Welche Entwickler welcher Bibliotheken meinst du genau, die früher KDE nutzten und heute nicht mehr? Mir ist da jetzt keine wichtige Bibliothek bekannt auf die KDE Software aufbaut und nicht auch KDE Nutzer unter den Entwicklern sind oder sogar KDE Entwickler mitentwickeln. Klingt nach einer sehr pauschalisierenden Aussage von dir.
käme es ausserdem erst gar nicht zu dem Problem
welches Problem genau soll sich denn dadurch lösen? Wer sagt denn, dass die Entwickler der upstream Komponente alle KDE Software Komonenten nutzen und dann gerade auch noch über den Bug stolpern, den sie verursacht haben und dann noch realisieren, dass ihre Komponente dafür verantwortlich ist. Sorry, aber das ist ein bißchen schönes Weltdenken.
Aber weil KDE unbenutzbar ist zum produktiven Arbeiten, benutzen es nur wenige Masochisten.
Right... dazu muss ich ja dann nichts mehr sagen. Warum diskutiert jemand zu einer News über einen Release Candidat einer Software Suite deren Nutzer er als Masochisten ansieht? Müsste ihm die Software nicht so etwas von sch*** egal sein, dass er den Artikel meidet?
Wenn ich jetzt nicht ein bekannter KDE Entwickler wäre, sondern nur ein KDE Nutzer, würde ich annehmen, dass hier ein Troll schreibt. Aber als KDE Entwickler darf man sowas nicht sagen, da einem sonst nachgesagt wird, dass man Nutzer als "inferior humans" ansieht.
Ironischerweise wurde als KDE rauskam gesagt, dass KDE mit allen QT4-Versionen laufen soll. Prüft natürlich keiner.
Sorry aber ich weiß nicht was du damit sagen willst. Das macht nämlich keinen Sinn und kann daher nicht gesagt werden (Link bitte falls du da was hast). KDE Software hängt von einer gewissen Qt Version ab (4.x). Was wir garantieren ist, dass die Software auch mit 4.y (y > x) funktioniert - besser gesagt nicht wir garantieren das, sonder Qt. Bedeutet aktuell benötigt KDE Libs die Qt Version 4.7 funktioniert aber auch problemlos mit Qt 4.8. Bei mir hier funktioniert alles hervorragend mit Qt 4.8 und hat bis vor Kurzem auch mit Qt 4.7 super funktioniert. Seit in Debian Testing Qt 4.8 ist, hab ich das aber nicht mehr getestet...
In diesem Fall war es kein harmloser Bug (es war nur noch 1 Programm über Task-Leiste erreichbar, alle anderen auf diese Weise nicht mehr), da muß man eben darauf warten bis dies gefixt wurde.
Das ganze erinnert mich an Xubuntu-LTS-10.04, da konnte der Xfce-Dateimanager keine Detailansicht darstellen(evtl Absturz), nur Icon-Ansicht. Grund war ein Bug in libgtk*xy, released wurde es trotzdem. Man musste einen anderen Dateimanager nehmen und 2 Monate warten bis das gefixt war.
Zum vorzeigen war das nichts. Die Xfce-Leutchen konnten da nichts zu, aber der Nutzer macht da keinen Unterschied.
Sorry aber die Welt ist nicht so einfach wie man sich das als Nutzer manchmal vorstellt.
Die meisten User interessiert es nicht wieso ein Bug da ist, was die sehen ist die Basiskomponente Task-Leiste die ein Arbeiten unmöglich macht(Programme verschwinden). Punkt.
Und was die sehen ist: KDE
Bei meinem Xfce-Dateimanager-Beispiel reichte der angeführte Punkt für mich aus keine CDs mehr davon weiterzugeben.
damit hast du meine Frage nicht beantwortet. Wie stellst du dir das nun vor, wie man solche Probleme erkennen und beheben soll?
Btw. der Fehler ist bei mir nur auf einem meiner drei Systeme aufgetreten und dort so selten, dass ich nie es reproduzieren konnte.
Wenn 'ihr' auf externe Tools aufbaut dann seit ihr auch von denen abhängig. Entweder ihr nutzt Versionen wo bekannte Bugs nicht drin sind oder ihr meldet+wartet - oder ihr released trotz Bugs("sind nicht unsere Schuld")
Tja, bei mir war es nach nach über 2 Jahren das erste mal wieder KDE, und eines der ersten Dinge die ich dort sah: Taskleisten-Bug.
> Wenn 'ihr' auf externe Tools aufbaut dann seit ihr auch von denen abhängig.
> Entweder ihr nutzt Versionen wo bekannte Bugs nicht drin sind
Das ist keine upstream/downstream Abhängigkeit sondern Aufgabe der Distributionen keine fehlerhaften Versionen auszuliefern oder schnellstmöglich zu aktualisieren.
Der downstream (KDE) *kann* nicht die Korrektheit des upstream (Abhängige Bibliothek) garantieren, weil er niemals die exakte Upstream Version kennt oder verantwortet. Demzufolge dürfte man niemals releasen, da es immer möglich ist eine fehlerhafte ältere oder neuere Version einer Abhängigkeit zu installieren.
Bestenfalls ist es möglich, bekannte generelle Schwächen im upstream (Treiber....) großräumig zu Umschiffen - allerdings auf Kosten von evtl. einwandfrei funktionierenden Features.
Linux ist nicht IOS und KDE nicht Apple wo alles zentral kontrolliert wird und Du nur installieren kannst, was Cupertino Dir erlaubt.
Wenn Du damit nicht klarkommst bist Du in dem Distributionsmodell falsch aufgehoben und suchst nach IOS oder evtl. auch Android.
Schon bei Windows ist das (trotz signierter Treiber aber vor Metro) nicht mehr vollends gegeben.
Wenn bloß Deine Distro in dieser speziellen Hinsicht kontinuierlich Ärger macht, solltest Du überprüfen ob ihre Ziele mit Deinen Ansprüchen konform sind.
Bleeding edge am besten in rolling releases ist nicht für "einmal installieren und das läuft dann so die nächsten 5 Jahre" gedacht und LTS heißt auch nur "long time support" und nicht "ausgereift" (Ubuntu hat in 12.04 ein paar mächtige Klopper) - da die für Dich richtige Balance zwischen "neu" und "entgratet" zu finden ist allerdings allein Deine Aufgabe und die kann Dir auch beim besten Willen niemand abnehmen.
Zum Zeitpunkt unserer Entwicklung war 7.11 die aktuelle Mesa Version, Mesa 8.0 wurde im Februar veröffentlicht - einen Monat nach unserem Release. Nun kombinieren Distributionen Mesa und KDE wie sie lustig sind.
Wir haben weder Möglichkeiten das zu testen noch irgendwelche darauf Einfluss zu nehmen. Wir sind da komplett abhängig von den Distributionen. Manche Distributionen haben dann noch so tolle Ideen wie llvmpipe zu aktivieren ohne mit uns Rücksprache zu halten, also wild an unserer Codebasis ohne Sinn und Verstand rumzupatchen.
Nun wie genau sollen wir also nur die Versionen verwenden wo Bugs nicht drinnen sind? Bzw. wie sollen wir überhaupt wissen, dass in der nächsten Version welche zum Zeitpunkt unseres Releases noch in Entwicklung ist, Probleme auftreten werden?
Ich bitte um konstruktive Vorschläge. Ich suche seit Jahren nach einer Lösung für dieses Problem
Indem man eine Art KDE-testsuite für Mesa schreibt, welche genau die Funktionen abbildet, die benötigt werden. Das hilft den Entwicklern der entsprechenden niederschichtigen Bibliotheken zu verstehen mit welchen Designentscheidungen sie Kompatibilität brechen, und es macht das Blama-Game einfach.
Danke, dass du dich bereiterklärst diese testsuite zu schreiben. Ist etwas was wir schon lange wollten und endlich möchte das jemand machen. Finde ich echt super von dir *thumbsup*
Das ist nicht ironisch gemeint, sondern ernst. Solche Sachen brauchen viel Zeit und wir können da jede Hilfe gebrauchen. Unser Blur Effekt ist übrigens Bestandteil der Piglit testsuite.
Du hast doch gefragt, was man nur tun könnte. Von den Leuten, die KDE kaputt gemacht haben, kann man auch erwarten es wieder zu flicken.
Gibt es denn bislang überhaupt eine KDE-Testsuite?
Wenn die Entwickler der Bibliotheken wie früher selbst KDE nutzen würden käme es ausserdem erst gar nicht zu dem Problem. Aber weil KDE unbenutzbar ist zum produktiven Arbeiten, benutzen es nur wenige Masochisten.
Ironischerweise wurde als KDE rauskam gesagt, dass KDE mit allen QT4-Versionen laufen soll. Prüft natürlich keiner.
Wenn ich jetzt nicht ein bekannter KDE Entwickler wäre, sondern nur ein KDE Nutzer, würde ich annehmen, dass hier ein Troll schreibt. Aber als KDE Entwickler darf man sowas nicht sagen, da einem sonst nachgesagt wird, dass man Nutzer als "inferior humans" ansieht.
Sorry aber ich weiß nicht was du damit sagen willst. Das macht nämlich keinen Sinn und kann daher nicht gesagt werden (Link bitte falls du da was hast). KDE Software hängt von einer gewissen Qt Version ab (4.x). Was wir garantieren ist, dass die Software auch mit 4.y (y > x) funktioniert - besser gesagt nicht wir garantieren das, sonder Qt. Bedeutet aktuell benötigt KDE Libs die Qt Version 4.7 funktioniert aber auch problemlos mit Qt 4.8. Bei mir hier funktioniert alles hervorragend mit Qt 4.8 und hat bis vor Kurzem auch mit Qt 4.7 super funktioniert. Seit in Debian Testing Qt 4.8 ist, hab ich das aber nicht mehr getestet...