Kommentare zu: Wie man Entwicklern bei Bugs helfen kann http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/ From the land of wobbly windows Wed, 08 Feb 2012 18:42:16 +0000 hourly 1 http://wordpress.org/?v=3.3 Von: Martin http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-9022 Martin Sat, 16 Jan 2010 18:57:01 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-9022 <blockquote>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.</blockquote> 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 ;-) <blockquote>Wo befindet sich der Code? hast du eine Offline-Kopie?</blockquote> 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 ;-) <blockquote>und wie funktioniert das mit kubuntu vs kde allgemein. wie kommen die bugfixes in die verschiedenen distris?</blockquote> 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. <blockquote>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.</blockquote> Kann ich nicht, aber ich kann dir sagen wo du die Information findest ;-) http://techbase.kde.org

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.

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 ;-)

Wo befindet sich der Code? hast du eine Offline-Kopie?

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 ;-)

und wie funktioniert das mit kubuntu vs kde allgemein. wie kommen die bugfixes in die verschiedenen distris?

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.

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.

Kann ich nicht, aber ich kann dir sagen wo du die Information findest ;-) http://techbase.kde.org

]]> Von: phiphi http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-9021 phiphi Sat, 16 Jan 2010 18:00:44 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-9021 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! 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!

]]> Von: Martin http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8995 Martin Fri, 15 Jan 2010 07:34:55 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8995 <blockquote>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?</blockquote> Bei Wishlist passt das irgendwie nicht. Bugzilla ist einfach ungeeignet um Feature Requests zu verwalten. Wir machen auch nur sehr selten requests zu. <blockquote>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?</blockquote> 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. <blockquote>Wie hilfreich ist es, wenn man kein KDE-Trunk einsetzt? Einfach nur mit Bugs in Versionen <= der eigenen Version beschäftigen?</blockquote> Trunk ist immer hilfreich, weil es zeigt ob der Fehler in der nächsten Version behoben sein wird ;-)

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?

Bei Wishlist passt das irgendwie nicht. Bugzilla ist einfach ungeeignet um Feature Requests zu verwalten. Wir machen auch nur sehr selten requests zu.

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?

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.

Wie hilfreich ist es, wenn man kein KDE-Trunk einsetzt? Einfach nur mit Bugs in Versionen < = der eigenen Version beschäftigen?

Trunk ist immer hilfreich, weil es zeigt ob der Fehler in der nächsten Version behoben sein wird ;-)

]]> Von: HmpfCBR http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8989 HmpfCBR Thu, 14 Jan 2010 23:06:36 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8989 > 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? > 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?

]]> Von: Schumbi http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8982 Schumbi Thu, 14 Jan 2010 12:03:45 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8982 hm, Danke auch wenn ich das nun nicht erwartet hätte. Wie bringe ich denn das "aktuelle" kdevelop auf mein Karmic? hm, Danke auch wenn ich das nun nicht erwartet hätte. Wie bringe ich denn das “aktuelle” kdevelop auf mein Karmic?

]]> Von: Andreas http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8970 Andreas Thu, 14 Jan 2010 07:23:15 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8970 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... 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…

]]> Von: Martin http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8954 Martin Wed, 13 Jan 2010 17:23:56 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8954 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. 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.

]]> Von: Schumbi http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8952 Schumbi Wed, 13 Jan 2010 17:02:12 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8952 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 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

]]> Von: Martin http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8948 Martin Wed, 13 Jan 2010 15:59:49 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8948 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 ;-) 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 ;-)

]]> Von: sebastian http://blog.martin-graesslin.com/blog/2010/01/wie-man-entwicklern-bei-bugs-helfen-kann/comment-page-1/#comment-8946 sebastian Wed, 13 Jan 2010 15:38:20 +0000 http://blog.martin-graesslin.com/blog/?p=431#comment-8946 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? 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?

]]>