Development/Howto/Bugzilla

Aus Mandriva Community Wiki

Wechseln zu: Navigation, Suche
Mandriva Cooker Bugzilla Tipps & Tricks

Diese Seite beinhaltet Informationen zur korrekten Prozedur eines Bug Reports (Fehler Meldung) einer Mandriva Linux Distribution. Bevor du einen Fehler meldest, lies dir diesen Artikel durch und halte dich daran. Da die Software Entwickler überall auf der Welt leben und arbeiten, werden Bug Reports ausschließlich in englischer Sprache verfasst. Es wird von niemanden erwartet das er die Sprache perfekt beherrscht, solange du dich in der Lage fühlst irgendwie verständlich zu machen wo das Problem liegt, reicht das für einen Report aus. Ansonsten kannst du weitere Personen mit den gleichen Problemen suchen, die den Bug Report für dich schreiben.

Inhaltsverzeichnis

[bearbeiten] Bug Tracking System

Um Fehler von Mandriva zu melden gibt es eine zentrale Anlaufstelle: http://qa.mandriva.com. Dort wird die wohl bekanntesten open-source Bug-Tracking-Software genutzt, Bugzilla.

[bearbeiten] Vor dem melden ...

Als erstes brauchst du einen Bugzilla Account. Bugzilla nutzt nicht die von den meisten anderen Mandriva Services genutzten my.mandriva Accounts. Daher musst du dir erst einen Account auf dieser Bugzilla Seite anlegen

Danach überprüfe ob du wirklichen einen Bug Report schreiben musst. Mehrere Hunderte oder gar Tausende von Personen nutzen Bugzilla, vielleicht hat also schon jemand den Fehler vor dir gefunden?

[bearbeiten] Durchsuche Bugzilla

Nutze die Suchfunktion von Bugzilla um sicher zu gehen, dass das gleiche Problem nicht schon gemeldet wurde oder sogar schon gelöst wurde.


Normalerweise durchsucht Bugzilla nicht die Liste der RESOLVED gelösten Bugs (Fehler). Du kannst ihn aber dazu bringen, in dem du bei der Schnell-Suche einfach ALL vor den Suchbegriff setzt, zum Beispiel ALL rpmdrake. Mit etwas Glück wirst du dann feststellen das es für "deinen" Fehler bereits eine Lösung gibt bzw. das es mit der nächsten Version behoben wird.

Wenn du dich nicht so gut mit Bugzilla auskennst, kannst du auch eine Liste der kürzlich geschriebenen Berichte zu einem bestimmten Programm anzeigen lassen (nutze die "component" Liste) und suche die Resultate nach Fehlerzusammenfassungen ab.

Außerdem solltest du in die Errata Seite deiner Mandriva Linux Version schauen, ob der Fehler dort bereits gelistet ist.

Gibt es bereits ein ähnliches Problem, trage deine E-Mail in das email CC: Feld und gib einen Kommentar mit deiner Fehlerbeschreibung ab. Das erspart doppelte Bug Reports; ein aussagekräftiger, ausführlicher Bug Report stellt ein Problem besser dar, als mehrere einzelne Bug Reports.


[bearbeiten] Nutze die aktuellste Version

Stelle sicher, dass du die aktuellste verfügbare Version verwendest. Falls du Cooker nutzt, solltest du wissen wie man sein System aktuell hält. Falls du jedoch eine stabile Version verwendest, folge den Anweisungen zum Installieren von Updates um sicher zu gehen, das dein System auf dem aktuellsten Stand ist und prüfe ob das Problem weiter besteht.


[bearbeiten] Ist es gerechtfertigt?

Als nächstes, prüfe ob der Fehler den du melden möchtest überhaupt vom Mandriva Bug Resolution System bearbeitet wird. Es gibt zwei Arten von Fehlern, die damit bearbeitet werden. Erstens, wenn eine Komponente der Mandriva Linux Distribution ein solches Problem verursacht, so dass es am effektivsten vom Mandriva Entwicklungs Team gelöst werden kann und zweitens, sind Verbesserungsanfragen für Applikationen welche vom Mandriva Team entwickelt wurden oder das Einbauen von anderen Applikationen betrifft.

Probleme welche an andere Stelle besser bearbeitet werden können - wie zum Beispiel vom eigentlichen Entwickler der Applikation - sollten nicht im Mandriva Bug Resolution System gemeldet werden. Genauso wenig wie Verbesserungen für Anwendungen die nicht von Mandriva entwickelt wurden: Sie sollten direkt zu den entsprechenden Entwicklern gesendet werden.

[bearbeiten] Wird es noch unterstützt?

Alle Bug Reports sollten auf weiterhin unterstützten Versionen erstellt werden. Die Lebenszeit Karte listet alle Unterstützungszeiträume derzeitig unterstützter Versionen. Eine Veröffentlichung die dort nicht auftaucht, wird auch nicht weiter unterstützt. Bug Reports die auf einer nicht mehr unterstützten Version abgegeben wurden, sind sehr ungerne gesehen.


[bearbeiten] Eine Fehlermeldung erstellen

Wenn du sicher gestellt hast, das es zu dem Thema nicht bereits eine Fehlermeldung gibt, gib bitte genug Informationen an:

[bearbeiten] Die richtige Distribution

Die richtige "Distribution" zu wählen, ist der erste Schritt einer jeden Fehlermedlung (Bugreport). Die gewählt "Distribution" sollte die sein, die du auf dem Computer nutzt wo das Problem auf getreten ist.

Alle Alpha, Beta und RC Versionen sind Cooker Versionen, das zwar mehr als ein Snapshot aber weniger als eine "Official" stabile Version ist. Für alle Fehler der Alpha, Beta und RC solltest du Cooker als Distribution wählen. Gib bitte im Bericht selber an, welche Cooker Version du nutzt.

[bearbeiten] Korrektes Produkt, Komponente, Version

Du musst das richtige Produkt, die richtige Komponente und die richtige Version des Paketes wählen.

  • identifiziere welches RPM Paket das fehlerhafte Programm beinhaltet
  • welche RPM Paket eine bestimmte Datei beinhaltet findest du so raus: rpm -qf problematische-Datei
  • mehr Infos zu einem RPM Paket bekommst du mit: rpm -qi Paket-Name

Wenn du nicht heraus bekommst zu welchem Paket der Fehler gehört, lass dich nicht davon abhalten einen Bug Report auszufüllen. Mach einen guten Vorschlag und ergänze in der Beschreibung des Fehlers, das du dir nicht sicher bist, ob du dir richtige Version gewählt hast. Das Auswahlteam wird dir helfen dir richte Version zu finden, bevor der Fehler einem Paketentwickler zu geteilt wird.


[bearbeiten] Details

Details sind wichtig; lieber zu viel als zu wenig Informationen:

  • bestimme die RPM Version der Software: rpm -q Paket-Name
  • liste deine Hardware auf, wenn es ein Hardware-spezifischen Problem ist
    • lspcidrake -v gibt nützliche Informationen über Onboard, PCI, PCI-E und AGP Hardware
    • lsusb gibt nützliche Informationen über USB Hardware
    • lsmod gibt eine komplette Liste der geladenen Treiber aus
    • gib an, ob du eine i586 oder x86-64 Version der Distribution verwendest


    • lspcidrake -v provides useful information about onboard, PCI, PCI-E and AGP hardware
    • lsusb provides useful information about USB hardware
    • lsmod provides a full list of drivers loaded on your system
    • always state whether you are using the i586 or x86-64 version of the distribution
  • beschreibe genau was du getan hast, als der Fehler aufgetreten ist
    • kürze die Schritte zu einem Minimum an Schritten bzw. zur kürzest möglichen Datei
  • nenne jede Änderung an der Konfiguration die du gemacht hast

Fehlen wichtige Informationen in deinem Bug Report, wird das Auswahlteam den Report auf den NEEDINFO (mehr Informationen) Status gesetzt und ein Kommentar ergänzt, welche Informationen gebraucht werden. Reiche in so einem Fall bitte alle gewünschten Informationen nach.

[bearbeiten] Anhänge zum Bug-Report

Bugzilla Bug-Reports sind leider durch einige Implementationsdetail des Webinterface in der Länge begrenzt. Daher kann es passieren, das du einen Bug-Report in mehrere Stücke teilen oder Anhänge nutzen musst.

Wenn du eine Datei hast, du mit dem Problem zusammenhängt (e.g. ein MP3 welches nicht mit xmms abgespielt werden kann), kannst du es an deinen Bericht anhängen. Das beschleunigt die Lösung des Problems und erspart die Nachfrage nach mehr Infos. Längere Konfigurationsdateien sollten prinzipiell als Anhäng ergänzt werden.

[bearbeiten] Wenn dein Bug vorliegt

Nach du du deinen Bug Report angeben hast, wird er nach dieser Bug Policy bearbeitet. Das heißt, das ein Mitglied des Auswahlteams entscheiden wird ob es ein gültiger Report ist der die Aufmerksamkeit eines Entwicklers erfordert. Wenn dem so ist, werden sich sicher stellen, dass der Bericht ausreichend detailliert ist oder weitere Informationen von dir (dem Ersteller) erfragen. Danach wird der Bericht zur Lösung einem Entwickler zu geordnet .

[bearbeiten] Löse selbst dein Problem

Das geniale an OpenSource ist, dass du nicht auf jemanden warten musst, der den Fehler behebt - du kannst es selber tun (oder jemanden damit beauftragen).

Fertige Software-Quellcode-Patches sind gerne gesehen; aber, zögere nicht unfertige Vorschläge oder nur Teile der Lösung in die Fehlermeldung zu ergänzen. Sie können genauer zeigen wo der Fehler zu suchen ist.

Wenn der Patchversuch erfolgreich war, schreibe es zu deiner Fehlermeldung (z.B.: als Kommentar).

Persönliche Werkzeuge
Andere Sprachen