Gestern hab ich ja darüber geschrieben wie der Weg von Bug zu Fix ist. Nun hab ich einen wichtigen Punkt vergessen: Du, ja genau Du, kannst den Entwicklern dabei nämlich helfen. Du brauchst dazu nicht mal programmieren zu können.
Ich hatte ja erwähnt, dass etwa 40 % aller Bugs die für KWin gemeldet werden, bereits gemeldet sind. D.h. ich gehe hin suche den korrekten und markiere ihn als Duplicate. Ein Beispiel aus der Beta 1: KWin crashed after a Konqueror crash Uns ist kurz vor Beta 1 eine Regression in den Code gekommen und wie man an meinem Commit (erster Kommentar) sieht, war es eine Trivialität. Dieser Crash hat uns durch die ganze Beta 1 verfolgt und er hat entsprechend viele Duplicates. Aber alle Duplicate Markierungen sind von Entwicklern gesetzt und das muss eigentlich nicht sein. Das könnten die Nutzer übernehmen. In so einem Fall ist es wirklich einfach: der Backtrace ist immer gleich und DrKonqui hängt die möglichen Duplikate sogar an (einfach auf einen der Duplikate klicken).
Ein anderer Fall sind normale Bugs – auch hier kann uns jeder Nutzer eigentlich helfen. Wenn ein Bug aufgemacht wird, steht er zuerst auf "UNCONFIRMED". Hier könnte nun ein Nutzer eigentlich schauen ob das überhaupt stimmt. Ist die Beschreibung korrekt, lässt sich der Bug reproduzieren, etc. Also den Bug soweit aufbereiten, dass der Entwickler damit etwas anfangen kann. Typischer Fall eines Bugs: KWin is slow – please improve. Toll hilft nichts. Hier müsste nachgefragt werden, welche Hardware er benutzt, welche Anwendungen, ob Compositing aktiviert ist, etc. Für mich als Entwickler ist so eine allgemeine Beschreibung natürlich wertlos und in der Zeit die ich nachfrage, könnte ich Entwicklungsarbeit leisten.
Und selbst bei Crashes kann der Nutzer sehr einfach mithelfen. Viele Crashes werden ohne die Debug Pakete installiert zu haben gepostet. Da können wir dann gar nichts machen. Hier gibt es die Möglichkeit nachzufragen oder wenn ein Weg angegeben ist, wie man KWin crashen lassen kann, einfach reproduzieren und einen guten Crash anhängen.
Dennoch muss ich nachfragen um meine Bugliste sauber zu halten. KWin hat aktuell etwa 360 offene Bugs. Wenn ich die Liste durchgehe und manuell Duplicates suche dann bekomme ich idR in einer Stunde 10 Bugs weg. Nicht gerade viel. Viele Bugs haben einen Kommentar wie "Is this still an issue in KDE SC 4.3.3?" und danach ein halbes Jahr keine Antwort mehr. In so einem Fall kann der Bug zugemacht werden – scheint niemanden zu interessieren und war entweder nie ein Bug oder ist behoben. Auch das ist etwas was Nutzer übernehmen können.
Wenn ein Bug überprüft ist, dann kann er von "UNCONFIRMED" auf "NEW" geändert werden. Dies könnte von den Entwicklern nun genutzt werden um zuverlässig nach Bugs zu suchen. Die unnützen Bugs erscheinen gar nicht und der Entwickler kann sich einen Bug schnappen und ihn beheben ohne großen Verwaltungsaufwand. Ja das wäre die ideale Welt 🙂
Nun muss man natürlich nicht alleine als Nutzer plötzlich anfangen hier die Bugs zu durchforsten, sondern es gibt den KDE Bug Squad, der genau das macht. Regelmäßig veranstaltet die Gruppe Bug Days und aktuell gibt es auf forum.kde.org Bug Weeks. Der Bug Squad braucht übrigens immer Nachwuchs da viele Bug Jäger plötzlich abtrifften in die Entwicklung. So wurde die Überarbeitung von DrKonqui von einem Bug Squad Mitglied durchgeführt – Dario hatte einfach gesehen was nötig ist. Das Team beißt nicht und hilft immer weiter und Entwickler sind wirklich dankbar für die Arbeit. Also nichts wie los nach #kde-bugs.
Ach und natürlich braucht nicht nur KDE Nutzer, die bei Bugs helfen, sondern jedes Projekt.
=-=-=-=-=
Powered by Blogilo
Was ist eigentlich mit Bugs, die man wirklich nicht näher beschreiben kann? Ich habe immer ein schlechtes Gewissen wenn ich einen Bug melden will, aber keinerlei Ahnung habe man diesen reproduzieren kann.
Mal als Beispiel für KWin: Wenn man die Ozone-Fensterdekoration farbig nutzt, also die Farbe nicht dem Fenster anpasst, ist sie oft teilweise wieder grau, wenn sie kurz von einem anderen Fenster überdeckt wurde. Dies geschicht vor allem in der Nähe der Buttons und Programmicons. Und es passiert mit und ohne Compositing.
Aber… So sieht doch kein Bugreport aus, oder? Wie hättet Ihr als Entwickler sowas denn gern formuliert?
Ja doch das wäre ein guter Bugreport. Er erwähnt genau was passiert, hat eine Einschränkung auf eine Fensterdekoration und erwähnt, dass es mit und ohne Compositing auftritt. Vorteilhaft wäre dann noch wenn es einen Screenshot dazu gibt.
Nun den Bug brauchst du aber nicht mehr melden, weil Ozone in 4.4 rausfliegt und wir uns um die Altlasten dann nicht mehr kümmern 😉
Ich habe bis vor kurzem mit Kdevelop entwickelt und es stürzte mir regelmäßig während des Beendens ab. Der Backtrace wurde erstellt allerdings ohne Debug-Symbole. Daraufhin habe ich versucht mich zu informieren, wie ich die Debug-Symbole erzeugen kann und versucht die *-dbg Pakete für kdevelop zu installieren. Irgendwie war es mir zu kompliziert und brachte nicht sehr viel. Der nächste Backtrace sah wieder recht mager aus. Könntest Du vielleicht kurz beschreiben, wie man es speziell bei Ubuntu hin bekommt? Ich nutzte nur kdevelop und nicht das komplette KDE Paket.
lG Schumbi
zu kdevelop scheint es in Ubuntu kein -dbg Paket zu geben. Und im Falle von Karmic ist auch zu sagen, dass das Paket nicht besonders gut ist – es wurde eine veraltete Beta Version paketiert. Durch das Melden der Crashreports nervt man dann eher die Entwickler als ihnen zu helfen.
kdevelop ist ein schönes Beispiel, wie es nicht sein sollte. Hier kommen viele falsche Dinge zusammen.
Dadurch, dass eine veraltete Beta paketiert wurde, entstanden viele überflüssige Bugreports. Fehler Nr. 1
Diese Flut an “duplicates” hat dann zu Duplicate-Markierungen geführt, selbst dann, wenn es eigentlich kein Duplicate war. Fehler Nr. 2
Und diese falschen Duplicates haben dann, zumindest bei mir, die Unlust Bugs zu melden enorm gefördert. Fehler Nr. 3
Sowas sollte wirklich vermieden werden, denn wir wollen ja eigentlich alle nur das Beste, und ich unterstelle auch allen Beteiligten, dass sie nach bestem Wissen und Gewissen handeln.
Bug-Management ist ein schwieriges Geschäft. Vielleicht sollte man mal über ein Projekt-übergreifendes QS-Team nachdenken, das sich dieser Aufgabe widmet…
hm, Danke auch wenn ich das nun nicht erwartet hätte. Wie bringe ich denn das “aktuelle” kdevelop auf mein Karmic?
> Wenn ein Bug überprüft ist, dann kann er von “UNCONFIRMED” auf “NEW” geändert werden.
Wie sieht das mit wishlist markierten Bugs aus? Sollten die auf unconfirmed stehen bleiben, bis daran gearbeitet wird, oder gibt es hier andere Kriterien, wann diese als New oder was auch immer markiert werden sollten?
Was ist mit Bugs die noch KDE 3.X betreffen, sollten solche einen Kommentar wie, “Is this still an issue in KDE SC 4.3.4?” erhalten, so dass die “halbe Jahr Regel” greifen kann?
Wie hilfreich ist es, wenn man kein KDE-Trunk einsetzt? Einfach nur mit Bugs in Versionen <= der eigenen Version beschäftigen?
Bei Wishlist passt das irgendwie nicht. Bugzilla ist einfach ungeeignet um Feature Requests zu verwalten. Wir machen auch nur sehr selten requests zu.
Kommt drauf an: ist die Funktionalität in 4.x nicht mehr vorhanden, dann kann der Bug direkt als RESOLVED UNMAINTAINED geschlossen werden, weil wir keine Fehler zu KWin in KDE 3 beheben. Ansonsten gilt die Regel mit dem Nachfragen.
Trunk ist immer hilfreich, weil es zeigt ob der Fehler in der nächsten Version behoben sein wird 😉
Hallo Martin
Ich habe soeben deine zwei Beiträge gelesen und fand sie sehr interessant. Ich habe noch keine Entwicklungserfahrungen, aber habe auch schonmal ein paar Bugs gemeldet.
Es sind ein paar Fragen aufgetaucht:
Wie testest du Bugs und Fixes, wenn du das Programm selbst verwendest. Testest du in einer virtuellen Maschine? wie geht das? wird der geänderte code direkt kompiliert und dann im laufenden system eingefügt? es kann ja gut sein, dass du während dem Fixen einen Fehler machst und dann würdest du dir das laufende system zerschiessen.
Wo befindet sich der Code? hast du eine Offline-Kopie? eine Kopie auf Git(orius)und eine auf svn.kde.org? gibt das nicht ein durcheinander? und wie funktioniert das mit kubuntu vs kde allgemein. wie kommen die bugfixes in die verschiedenen distris? müssen die immer wieder manuell von jeder distri aufgenommen werden?
Könntest du nicht erklären, wie man das ganze einrichtet, damit man wenigstens mal in den code schauen kann. er scheint mir irgendwo ganz weit weg zu liegen.
übrigens für nicht entwickler hast du zumindest im ersten artikel ziemlich viele begriffe und abkürzungen verwendet. beispiel bei der erklärung wie der bug in die aktuelle version zurückportiert wird.
vielen dank!
Normalerweise habe ich einen zweiten X-Server und auf dem zweiten Server läuft ein Testsystem. Aktuell hab ich aber Probleme beim Wechseln zwischen den X und teste wirklich live im produktiven System und ja da besteht die Gefahr mal was kaputt geht. Motivation noch genauer aufzupassen 😉
Ja ich hab hier eine Offline Kopie – also den aktuellen Code einmal ausgecheckt. Git verwende ich nur lokal und ist mit svn synchronisiert. Gibt also kein Durcheinander 😉
KDE veröffentlicht ja in regelmäßigen Abständen neue Versionen. Also demnächst wird es wohl ein KDE SC 4.3.5 mit allen Bugfixes seit 4.3.4 geben. Der Quellcode wird dann in ein tar.gz Archiv gepackt und den Distributionen zur Verfügung gestellt. Manchmal nehmen sie auch einzelne Patches aus noch unveröffentlichten Versionen – ist aber recht viel Aufwand.
Kann ich nicht, aber ich kann dir sagen wo du die Information findest 😉 http://techbase.kde.org