Re: Probleme mit Debian Stretch
Hallo Matthias,
Am Donnerstag, 3. September 2015, 08:20:18 schrieb Matthias Bodenbinder:
> Am 03.09.2015 um 07:18 schrieb Mechtilde:
> > Die Pakete wandern automatisch von Unstable nach Testing wenn in der
> > Karenzzeit von 2 bis 10 Tagen keine kritischen Fehler gefunden werden.
>
> Dann frage ich mich wieso innerhalb von 2-10 Tagen niemand in unstable
> bemerkt das KDE kaputt ist? Das kann doch gar nicht sein, das ein komplett
> zerbrochener Desktop nicht auffällt.
Bemerken? Natürlich bemerke ich das. Aber wo steht, dass ich verpflichtet bin,
den Fehler zu berichten? Wenn ich davon ausgehe, dass das Problem temporär
ist, mache ich das oft nicht. Ja, jetzt könnte ich die Policy natürlich
hernehmen und sagen, Testing soll keine RC-Bugs enthalten. In einigen Fällen
waren Fehler aber schon wieder behoben, bevor das Paket nach Testing
migrierte. Wenn ich dafür Fehlerberichte schreibe, erhöhe ich den Aufwand für
die Entwickler noch, es sei denn ich schließe den Fehler sofort wieder, wenn
er behoben ist, was mir zusätzlichen Aufwand macht.
Wer ist nun dafür verantwortlich, die Policy umzusetzen? Die Entwickler? Wohl
am ehesten. Aber solange es bei Debian keinen Mechanismus gibt, Transitionen
erstmal vollkommen von Testing getrennt vorzubereiten, *ohne* dabei den
üblichen Entwicklungsprozess über Gebühr zu behindern, weil andere Entwickler
auf die Transition warten, sehe ich nicht, wie das gehen soll.Die Entwickler
wussten in einigen Fällen selbst nicht, was zerbrechen würde, und warum. Und
wenn die wenigen Entwickler in allen Fällen, wo sie ein Problem bemerken,
selbst RC-Bugs schreiben, um Pakete von Testing fernzuhalten, dauert alles
noch länger. Ich denke für die G++ ABI-Transition wäre ein PPA vielleicht
wirklich eine Idee, da Maintainer von Paketen, die kein C++ verwenden, diese
dann ohne Weiteres weiterhin nach Unstable hochladen könnten. Selbst für
Pakete mit C++-Software geht das, verursacht aber den zusätzlichen Aufwand für
eine Zeit zwei Versionen zu pflegen (zusätzlich zu der Version für Stable und
ggf. Oldstable).
Das wäre dann die Diskussion zum "always releaseable testing". Eine schönes
Ziel. Aber eben noch keine Realität. Nun ist es möglich, darüber zu klagen.
Ändert nur nichts. Oder es ist möglich was zu tun. Und IMHO kann sich so gut
wie jeder entsprechende Fähigkeiten aneignen. "Ich kann das nicht ist" ist
also für mich keine Ausrede. Ja, es kostet Zeit. Aber wenn ich schon keine
Zeit dafür aufwende, erwarte ich auch nicht von den Entwicklern, dies
zusätzlich zu der Zeit, die sie ohnehin schon – oft unbezahlt und in ihrer
Freizeit – aufwenden, dies zu tun. Wäre auch sinnlos, weil meine Erwartung
nicht automatisch dazu führt, dass sie es tun. Direkt kann immer nur mein
eigenes Verhalten verändern.
Eine Möglichkeit wäre z.B. selbst Unstable in eine VM zu installieren und
gezielt einen RC-Fehler zu berichten, wenn z.B. der Desktop in Unstable nicht
mehr startet. Und diesen dann bitte auch sofort wieder zu schließen, wenn das
Problem behoben ist. Nun schaue ich mich hier um und frage: Wer von denen, die
hier Forderungen stellen, ist bereit, sich entsprechend einzuarbeiten und dies
dann zu tun? Es ist gar möglich, z.B. für Plasma/KDE auf #debian-kde dann auch
erstmal nachzufragen und auf #debian-qt-kde erstmal mit den Entwicklern
persönlich zu chatten, gegen welches Paket der Bugreport Sinn macht.
Vielleicht ergibt das sogar sofort eine Lösung mitsamt Paket-Upload.
Ich sehe es für mich derzeit nicht ein, die Zeit zu investieren, RC-Bugs zu
erstellen für transiente Probleme. Ich helfe lieber, Bugreports, die nicht
mehr zutreffen zu schließen. Und die Probleme rauszufinden, die eben nicht
transient sind, also wirklich eine eine zusätzliche Änderung am Paket
brauchen, um sie zu beheben. So wird das Paket für kwalletd5 derzeit nicht
automatisch installiert, wodurch z.B. der Owncloud-Client dann nicht die die
KDE-Brieftasche zugreifen kann (Tipp: libkf5wallet-bin installieren), und in
der Zeit, in der ich diese Mail schreibe, hätte ich den entsprechenden
Bugreport gleich fünfmal schreiben können.
Ich gehe nicht davon aus, dass eine Diskussion hier auf der deutschsprachigen
Anwender-Mailingliste irgendetwas ändern wird, oder eine Petition an die
Entwickler oder etwas in der Art. Mithelfen hingegen schon. Wer also ein
Interesse hat, dass Testing immer releasefähig ist, der darf da auch gerne
selbst etwas für tun. Mir ist das ehrlich gesagt persönlich trotz Policy
vollkommen schnuppe. Da ich Testing nicht mal nutze. Ich möchte lieber, dass
diese Transition so schnell wie möglich durch ist. Und daher vermeide ich
alles, was aus meiner Sicht den Entwicklungsprozess ausbremsen würde, und
versuche stattdessen da zu helfen, wo ich es möchte. RC-Bugs öffnen und (!)
bei Beheben gleich wieder Schließen ist für Testing-Nutzer IMHO durchaus
sinnvoll. Meine Priorität ist es nicht.
Und ja, Hilfe in Bezug auf Testen und Bugreports ist zumindest seitens des
Debian Qt/KDE-Teams gerne gesehen. Das Team braucht mehr Leute, die testen und
konstruktiv (!) auf Fehler aufmerksam machen.
Also willkommen in der Welt, in der nicht alles 100% der Policy entspricht. Du
darfst gerne mithelfen, dies zu ändern.
Ciao,
--
Martin
Reply to: