Frust mit Bugzilla

Das Melden von Bugs im Bugzilla von Red Hat/Fedora macht teilweise keinen Spaß mehr, wenn man miterlebt, das eigene Bugreports, die man z.T. für Pakete aus Fedora 13 angelegt hat, jetzt automatisch geschlossen werden, ohne das es seit dem Anlegen des Bugreports irgendeine Reaktion der Verwalter des betroffenen Paketes gab. Einige der Bugreports wurden mit Fedoras abrt1 erstellt, was sie aber auch nicht davor bewahrt hat, komplett ignoriert zu werden.

Bin ich der einzige oder geht das auch anderen Lesern so?

  1. automatic bug reporting tool []

8 Antworten auf „Frust mit Bugzilla“

  1. Du bist nicht der Einzige.
    Ich logge zwar immer noch Bugs, aber ich habe jede Hoffnung aufgegeben das jemals einer behoben wird. Meistens verschwinden die nach einer handvoll Releases ohne das sich jemand darum kümmert.
    Bei Hardware Problemen gebe ich es direkt auf und kaufe etwas anderes.
    Und ich will überhaupt nicht Anfangen mit der Anzahl von Problemen die Gnome3 mit sich bringt. Nicht nur Bugs, aber auch Features die einfach verschwunden sind. Aber alles was damit zu tun hat ist sowieso hoffnungslos.

  2. Um ehrlich zu sein, gehe ich allmählich dazu über, Bugs „upstream“ (d.H. beim jeweiligen Projekt) zu melden, in der Hoffnung, das es dort besser läuft.

  3. Ist keine Neuheit. War schon vor langem Thema auf einigen Mailing Listen. Zu einigen Paketen gehen Hunderte (teilweise Tausende) Bug Reports ein. Schau beispielsweise mal unter:

    http://bugz.fedoraproject.org/nautilus
    http://bugz.fedoraproject.org/evolution
    http://bugz.fedoraproject.org/rhythmbox
    http://bugz.fedoraproject.org/kernel

    Es gibt schlichtweg nicht genug Leute (Entwickler eingeschlossen), die all diese Tickets gewissenhaft bearbeiten und dabei zudem noch die upstream Entwicklung berücksichtigen.

    Upstream sieht es auch nicht generell besser aus. Das ist von Projekt zu Projekt verschieden. Manchmal werden einzelne (triviale?) Bugs zwar noch bearbeitet, ältere sammeln sich aber an.

    Bei Fedora kommen noch Pakete hinzu, die innerhalb von Fedora aus diversen Gründen schlecht betreut sind. Die Mentalität „wen etwas stört, der darf sich gerne selbst um den fix bemühen“ ist stellenweise verbreitet. Mangels Reaktion seitens des Paketierers innerhalb von bugzilla ist so ein Zustand aber oft schwer erkennbar. Nach Wochen oder Monaten weiß man mehr und hat dann mit einem Kapitel vielleicht schon abgeschlossen.

    Grundsätzlich gilt aber: hat man Interesse an der Software und/oder den Fedora Paketen, sollte man irgendwie versuchen sich einzubringen.

  4. Ich habe für mich persönlich den Standpunkt

    mehr als möglichst detailierte Bugreports schreiben kann ich auch nicht tun

    Ich bin zwar ausgebildeter Fachinformatiker AE, aber wenn ich zu hause auch noch anfange stundenlang zu programmieren, krieg ich wahrscheinlich Ärger mit meiner Frau 😉

  5. Als jemand, der einen Haufen Pakete bei Fedora betreut, möchte ich hier mal die andere Seite darstellen:

    Zuerst einmal muss man unterscheiden, ob es sich um einen automatisch generierten Bugreport von ABRT handelt oder ob er von Hand eingetragen wurde. ABRT hat den Vorteil, dass es bei Programmabstürzen automatisch Backtraces erstellen kann und den Benutzern damit Arbeit abnimmt. Leider führt dies aber auch dazu, dass sich eine „File & forget“ Mentalität breit macht: Man braucht einfach immer nur „Weiter“ zu klicken und erhält zum Schluss einen fertigen bug report. Nur die wenigsten Leute machen sich wirklich, die Mühe zu schreiben, was sie taten, als der Bug aufgetreten ist und wie man ihn reproduzieren kann. Also muss man diese Informationen erst mühselig erfragen und auch darauf kommen meist keine Antworten. Meiner Erfahrung nach sind 80-90% der Bugs, die mit ABRT erstellt wurden, aus diesem Grunde unbrauchbar.

    Abgesehen davon sollten Programmabstürze direkt an die Entwickler und nicht an die Paketbetreuer gemeldet werden, denn sie sind nur sehr selten auf eine falsche Paketierung zurückzuführen. Dr. Konqi von KDE beispielsweise nutzt bugs.kde.org und nicht bugzilla.redhat.com.

    Das gleiche sollten meiner Meinung nach auch die Benutzer machen, zumindest die ambitionierten. Den Bugreport einfach in den Bugtracker der Entwickler kopieren und dann als externe Referenz angeben. Das erspart den Maintainern, die teilweise hunderte ABRT bugs haben, eine Menge Arbeit. 200-300 offene ABRT bugs sind keine Seltenheit, viele davon Duplikate, aber alleine die zu finden ist schon eine Menge Arbeit.

    Ich kann aber auch verstehen, dass nicht jeder Nutzer direkt mit jedem Entwickler eines Programms kommunizieren will oder kann und als Paketbetreuer bin ich auch gerne bereit, als Brücke zwischen beiden zu dienen: Ich überprüfe die Vollständigkeit der Informationen und leite die Berichte weiter, sobald sie komplett sind. Aber das geht nur, wenn Entwickler und Nutzer wirklich aktiv sind. Der Entwickler muss weitere Informationen erfragen und der Nutzer muss sie liefern. Ich vermittele zwischen beiden und auch das ist viel Arbeit.

    Bei den manuell eingetragenen Bugs ist es nicht ganz so schlimm. Wer sich die Mühe macht, einen Fehler einzutragen, ist meist auch bereit, weitere Informationen zu liefern. Aber auch hier bleiben viele Bugs auf der Strecke, ich denke mal um die 40-50%. Ich frage 2 mal nach und setze nochmal „NEEDINFO“ aber wenn dann nichts kommt, schließe ich den Bericht „INSUFFICIENT DATA“.

    Aus diesem Grunde ist es nicht nur bei Abstürzen sinnvoll, Fehler direkt an die Entwickler zu melden. Feature requests beispielsweise muss man mit den Entwickler besprechen und nicht mit dem Pakebetreuer. Im bug tracker des Projektes gibt es auch mehr Interessierte, die über das gewünschte Feature diskutieren können.

    Lange Rede kurzer Sinn: Ich denke, es ist nicht so schlimm, wie man nach Lesen dieses Artikels denken könnte. Die Bugs werden ja nicht automatisch geschlossen, der Nutzer wird nut aufgefordert, zu überprüfen, ob der Bug noch aktuell ist und ggf, die Verion entspechend zu ändern. Bei ABRT bugs ist es halt so, dass ein backtrace von evolution 2.28 ein Jahr später nicht mehr viel über evolution 2.32 aussagt. Selbst wenn der gleiche Bug noch besteht, hat sich der Code doch so verändert, dass die Zeilenangaben etc. aus dem trace nicht mehr stimmen.

    Bei ABRT bugs also bitte immer mit dazu schreiben, was genau man vor dem Absturz getan hat und ob es nur ein gelegentlicher Absturz ist oder das Programm immer wieder abstürzt, wenn man die gleichen Schritte wiederholt.

    Frustration gibt es sicherlich auf beiden Seiten: Ich ärgere mich schwarz, wenn ich immer wieder die gleichen Fragen stellen muss und keine Antwort erhalte oder wenn ich ein Update veröffentliche, und keiner der 10 Leute, die den Bug gemeldet haben, das Update testet und mir Feedback gibt.

    Es gilt die Frustration zu überwinden und das geht nur, wenn Benutzer, Maintainer und Entwickler an einem Strang ziehen.

  6. @ Heiko : Stundenlanges Programmieren meine ich nicht. Bugs zu melden, anstatt ABRT zu ignorieren, ist auch ein Beitrag – und weitaus praktikabler für die Masse der Nutzer. Upstream läßt sich ggf. ein Link auf Fedora Bugzilla eintragen, was die Sache vereinfacht. Das wiederum ist leider nicht immer wirklich einfach, da erstmal jemand klassifizieren muß, wo genau ein Problem überhaupt liegt. In der App? In einer Lib? Instabile Hardware? Undefiniertes Verhalten als Folge unbekannter/unerwarteter Nutzung oder unglücklicher Integration? Hat der Entwickler wirklich einen Plan und kennt seinen Quelltext? Oder stellt komplexes Verhalten von Libs eine Hürde dar?

    Fedora sollte sich jedenfalls fragen, was die Nutzer Community von Bugzilla, ABRT und den Paketierern erwarten darf. Ich rate allen Nutzern, die sich über einen ABRT Bug Report hinaus engagieren möchten, dies zeitig zu kommunizieren.

    ABRT macht es Otto Normal zu einfach, etwas nahezu automatisiert zu übermitteln und die Sache damit als erledigt zu betrachten. Und ohne die Bereitschaft für Rückfragen und weitere Analyse zeigen zu müssen. Als Ergänzung zu Christophs Post, es ist sogar schwer, Leute zu animieren, ein Test Update auszuprobieren. Ich denke, viele mögen gar nicht solche Verantwortung, ein Urteil über ein Update zu fällen.

    Aber: Fedora bietet nunmal Möglichkeiten für Interessierte, sich auch als Beobachter zu beteiligen und beispielsweise die Bugzilla und Package Git Aktivitäten zu überwachen (per „watchbugzilla“ und „watchcommits“ in der pkgdb). Zusätzlich ein waches Auge auf updates-testing zu richten. Entsprechendes Interesse an bestimmten Fedora Paketen vorausgesetzt, kann man so bereits die reine Konsumentenrolle verlassen und die Paketqualität aktiv beeinflussen, anstatt nur nachträglich Fehler in Updates zu monieren.

  7. Vielleicht sollte man abrt so erweitern, dass das Tool auch mehrere Bugzillas gleichzeitig „bestücken“ kann (oder geht das schon?) und die wichtigsten (Gnome. KDE, LibreOffice und Mozilla) soweit möglich vorkonfigurieren. Dann könnte abrt für einen diese Doppelmeldungen (Up- und Downstream) machen, sofern man über die entsprechenden Accounts verfügt

    1. Theoretisch kann man ABRT auch mit andern Bugzillas benutzen, das Problem ist, dass man die Bugs den richtigen Programmen zuordnet und nicht immer heißen die Programme so wie die Pakete in Fedora.

      Es führt also erst mal kein Weg dran vorbei, die Sachen weiterhin in unser Bugzilla zu stellen. Aber die Bugs dann entsprechend weiterzuleiten ist in der Regel kein Problem und meiner Meinung nach auch nicht viel Aufwand (2 min), vorausgesetzt man weiß, wo der Tracker ist und hat einen Account.

      Bei ABRT sehe ich eigentlich keinen Grund für Doppelmeldungen. Da kann man den upstream bug dann als externe Referenz angeben (gibt sogar für die populärsten Bugzillas schon ein Extra-Feld, ansonsten nimmt man „URL“) und unseren bug getrost als „CLOSED UPSTREAM“ schließen. Klar, gefixt ist er damit noch lange nicht, aber „CLOSED UPSTREAM“ heißt genau das: Die Entwickler kümmen sich drum. Meist werden die Maintainer den upstream bug als CC abonnieren und bekommen so mit, ob/wann er gefixt wird.

      Das sollte man aber nicht mißbrauchen, also nicht alles einfach so schließen, sondern nur ABRT bugs oder die Sachen, bei denen sich die Entwickler auch wirklich des Problems angenommen haben.

Kommentare sind geschlossen.