Development/Howto/Bugzilla
Aus Mandriva Community Wiki
Not just for beginners!
Inhaltsverzeichnis |
[bearbeiten] Introduction
[bearbeiten] Vorwort
Das ist die erste Version des Mandriva Bugzilla HOWTO; Wie du siehst ist noch einiges zu tun und du bist eingeladen deine Tipps, Tricks und Ideen zu ergänzen. Möchtest du ein neues Feature vorschlagen, dann melde dich auf der Cooker mailing list an und schreibe sie in die Bugzilla Wishlist
[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 ...
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 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.
If you are not familiar with Bugzilla, at least list all currently reported bugs for the program (using the "component" list), and scan the resulting list of bug summaries.
If there is a problem similar to yours, add yourself to the email CC: field and add your problem description to the comments. This avoids duplicate bug reports; one comprehensive bug report gives a better picture of the problem than several individual bug reports.
[bearbeiten] Nutze die aktuellste Version
Schau in das "Change Log" der installierten Version deiner lieblings Software bevor du einen neuen Fehler meldest. Eventuell gibt es bereits eine neue Version in der der Fehler bereits behoben wurde.
Mandriva nutzt RPM-Pakete zum installieren neuer Software, diese enthalten das "Change Log". Du startest am besten die grafische Oberfläche des Paketmanagers (rpmdrake) und wählst das Paket aus. In der unteren Fensterhälfte findest du eine kurze Beschreibung des Paketes und darunter auch das Change-Log, was du aufklappten kannst. In der Konsole kannst du mit Hilfe der Befehle urpmi.update und urpmq. Voraussetzung dafür sind aber korrekt eingerichtete Paketquellen. Dazu schaust du dir am besten folgenden Artikel zur Softwareverwaltung an.
Wenn du direkt zu der "frischsten" Version der Software gehen willst, solltest du online den Change-Log Bereich der RPM SPEC Datei der Software lesen. Zum Beispiel:
- SPEC files(für Main-Repository), contrib-SPEC files(für Contrib-Repository)
- wähle dein Programm (Komponente)
- klick auf 'Diff to previous' (bunt ist irgendwie schöner)
- und suche am rechten unteren Bereich der generierten Seite den Change-Log-Bereich der neusten Version
Wenn dein Problem als "Solved" (gelöst) im Change-Log geführt wird, probiere die Version zu installieren. Installiere bitte prinzipiell erst die neuste Version bevor du etwas meldest; melde keine Bugs für ältere Versionen der Software.
[bearbeiten] Klappt es mit einer früheren Version?
Angenommen du hast die Version A deines Lieblingsprogramm benutzt und du führst ein Update auf Version D aus, dass jetzt plötzlich nicht mehr funktioniert.
Weiter angenommen dass es eine Lücke zwischen Version A und D gibt, es also noch weitere Versionen dazwischen gibt. Also du beispielsweise von Version 2 zu Version 5 gesprungen bist, liegen Version 3 und 4 dazwischen.
Bevor du einen Fehler meldest, prüfe welche Version die letzte funktionsfähige ist und welche die erste Version ist, die den Fehler verursacht. Probiere den Fehler zu reproduzieren und beschreibe das in der Meldung, so dass es den Softwareentwicklern möglich ist den Fehler genau zu lokalisieren.
[bearbeiten] Löse selbst dein Problem!
Auf jeden Fall kannst du auch selbst probieren den Fehler zu beheben. 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).
[bearbeiten] Submitting a new bug report
If you have done searches to assure yourself that your bug report is the very first one on this topic, please post enough information:
[bearbeiten] Correct Distribution
Choosing the correct "Distribution" is the first step in filing the bug report. The "Distribution" chosen should be the one that is in use on the computer system where the problem with the software exists.
All bug reports should be made against the most current distribution. Check the published life cycle of the distribution release that is in use on the system. If it is no longer supported, upgrade and see if the bug still exists. Bug reports against distribution releases that are no longer in the support cycle cannot be processed.
Note that all Beta and all RC releases are Cooker releases that are more than a snapshot but less than an Official stable release. So all bugs reported on a Beta or RC should be against the Cooker Distribution. Please also state in the report which version of cooker applies.
[bearbeiten] Correct product, component, version
You must select the correct product, component and version of your package.
- identify which RPM package "owns" the program with the bug
- you can find out which software RPM package "owns" a file by: rpm -qf problematic-fil
- more RPM package info is available using: rpm -qi package-name
Again, test your problem with the latest version.
[bearbeiten] Details
Details are important; provide more rather than less information:
- find the RPM version of software: rpm -q package-name
- describe your hardware if this is a hardware-related problem
- useful tools: lspcidrake -v, lsusb, lsmod, etc.
- describe exactly what you did to cause the bug to appear
- trim down the steps to the smallest file and smallest set of actions that cause the problem
- etc.
[bearbeiten] Attachments to bug reports
Bugzilla bug reports are unfortunately limited in length due to an implementation detail of the Web interface. You may find you have to submit a long bug report in several pieces, or use attachments.
If you have a data file that is related to your problem (e.g. an MP3 file that does not play under xmms), you can attach it to your bug report. Doing this speeds up bug resolution and you can save one NEEDINFO -> NEW cycle.
[bearbeiten] When your bug is submitted
Bug reports have various status keywords as they are processed:
[bearbeiten] A Typical Bug's Life
UNCONFIRMED
| |
| |-------<------+
| | |
| NEW --->--- NEEDINFO
| |
| |--------<--------+
| | |
| ASSIGNED --->--- NEEDINFO
| |
| |
RESOLVED (FIXED, INVALID, DUPLICATE, WONTFIX, WORKSFORME)
[bearbeiten] UNCONFIRMED status
You have just submitted the bug and it is waiting for other people to corroborate (to tell that they have the same bug). Bug reports that have a lot of corroboration get attention first. If your bug report is in a little-used piece of software, or is triggered by a special case, the bug may stay UNCONFIRMED for a long time. For best response, get other people who can reproduce the same bug to add comments to your bug.
[bearbeiten] NEW status
Your bug is confirmed (or: the maintainers agree that this is a real problem) and is now waiting to be assigned to a specific software maintainer.
[bearbeiten] ASSIGNED status
A specific software maintainer has been assigned to handle this bug report.
[bearbeiten] NEEDINFO status
Some information is missing, and the maintainer is waiting for that information. Maintainers give low priority to bugs with NEEDINFO status, since they can't proceed with a fix until the information is provided.
When you provide the missing information, change the bug status back to NEW or ASSIGNED so that the maintainer knows the bug should be re-examined.
[bearbeiten] RESOLVED/DUPLICATE status
The maintainer thinks this bug is a duplicate of another bug. It is your job to read the original bug report carefully and, if this is not a true duplication, you should provide additional supporting information and re-open your bug report.
An example of a wrong DUPLICATE status is here - Bug #9450, Bug #4629.
[bearbeiten] RESOLVED/INVALID status
The maintainer thinks this isn't a bug. Perhaps the software is intended to work that way; or, perhaps something is wrong with your computer to cause it to work that way. If you disagree, re-open the bug report and provide additional supporting information.
[bearbeiten] RESOLVED/WORKSFORME status
The maintainer could not reproduce your bug.
[bearbeiten] RESOLVED/OLD status
The reported version or release is out of lifecyle, or the bug is already fixed.
[bearbeiten] Contacting software maintainers
Yes, your bug report is important; however, perhaps other bug reports are more important than yours. If you can't fix the bug yourself, have patience while waiting for the maintainer to fix it for you.
Do not bother software maintainers by contacting them over and over about your bug. If you think your bug is important, find others who can corroborate it and add additional supporting comments. Important bugs are ones that affect many people.
[bearbeiten] Testzilla Howto
Through the Testzilla pages on Bugzilla (latest results, hardware statistics, the rest of the links are on the Bugzilla main page), you can follow procedures to report successes or bugs on Bugzilla components.
To be able to perform hardware testing, you must first upload your system configuration to Testzilla Howto. To do so, install the hwdb-clients package and run hwdb_add_system <bugzilla account> "<system name>". Your profile will appear on the My Hardware page, and you will have access to the various hardware validation procedures from the the Testzilla section of the Bugzilla main page.
Consult the Testzilla Howto wiki page if you want to contribute procedures or see how the whole system works.
Bugzilla is the master database for bug reporting In order to make a bug report, you need to get a valid Bugzilla account, which is very easy. You just navigate with your browser to http://qa.mandriva.com/ and click on the "Open a new Bugzilla account" link and enter the information requested.
Normal accounts have privileges to add bugs, add comments to existing bugs and change the status of bugs that were created with that account. Before a new bug is posted, Bugzilla will perform a search of the database looking for similar bugs and will prompt you to make sure you want to post a new bug.
[bearbeiten] TODO: merge with page content
[bearbeiten] How Bugzilla Works
The web interface is the way most users interact with Bugzilla. The mandriva Bugzilla is located at http://qa.mandriva.com/
There is a mail interface to Bugzilla that makes it easy to add additional comments or change the status of bugs if you have the appropriate level of access.
[bearbeiten] Voting for Bugs
Bugzilla maintains a voting system for helping users validate bug reports. It is supposed to be used so that people can indicate that they have duplicated a bug and feel it is important, while hopefully reducing duplicate bug reports.
