Development/Howto/Bugzilla
From Mandriva
Not just for beginners!
Contents |
Introduction
Foreword
This is an initial release of a Mandriva Bugzilla HOWTO; it's not complete. You can add your own hints, tips and ideas. If you want to propose a feature, please discuss it on the cooker mailing list and then add it to the Bugzilla Wishlist.
Bug tracking system
There is one central place for reporting Mandriva bugs: http://qa.mandriva.com. It uses famous opensource bug tracking system called Bugzilla.
Before you submit a new bug
Hundreds and thousands of people use Bugzilla. Perhaps someone has already reported this bug?
Search Bugzilla
Search Bugzilla to ensure that there is no similar problem already reported, and that the problem is still outstanding. Duplicate bug reports waste time.
By default, Bugzilla does not search the list of RESOLVED bugs. You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL rpmdrake You may discover that your bug has already been resolved and fixed in a later release.
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.
Use the Latest Release
Check the change log of the latest version of your favourite software before you submit a new bug report. Perhaps your problem has already been fixed in a new release?
Mandriva software comes in RPM packages that contain a software change log. You may use the GUI interface rpmdrake' to download current descriptions of RPM packages (choose "update media") and examine the change log descriptions (choose "maximum information"), or you can use the command-line tools urpmi.update and urpmq to do the same thing.
If you want to go straight to the most recent version of software, you may also read online the %changelog section of an RPM SPEC file of your program or component. For example:
- SPEC files(for main repository), contrib-SPEC files(for contrib repository)
- select your program (component)
- click to 'Diff to previous' (colored is much nicer)
- and check for the bottom right part of the generated page, there is the %changelog section for the latest release.
If your problem is stated as solved in a change log, try installing that version. Always try the latest version of software before reporting a bug; do not report bugs against old versions of software.
Does a Previous Version Work?
Suppose you have been using version A of your favourite program. You perform a software update to version D and then your program/feature no longer works.
If there is a gap between version numbers A and D, it means that other versions exist between these versions. For example, if you went from version 2 to version 5, versions 3 and 4 lie between 2 and 5.
Before you post your bug report, find out which is the latest version that works, and which is the version that first caused the problem. Identify exactly when things broke, so that the software maintainers can pinpoint the problem.
Solve Your Own Problem!
By all means, try to solve your own problem and fix the bug! A fabulous feature of open source software is that you don't have to wait for anyone to fix bugs - you can do it yourself (or hire someone to do it).
Finished software source code patches are welcome; but, do not hesitate to add unfinished guesses or partial fixes to your bug report. They can show more precisely where the problem is.
If you are successful in patching the problem, add your patch to your bug report (perhaps as a later comment).
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:
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.
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.
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.
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.
When your bug is submitted
Bug reports have various status keywords as they are processed:
A Typical Bug's Life
UNCONFIRMED
| |
| |-------<------+
| | |
| NEW --->--- NEEDINFO
| |
| |--------<--------+
| | |
| ASSIGNED --->--- NEEDINFO
| |
| |
RESOLVED (FIXED, INVALID, DUPLICATE, WONTFIX, WORKSFORME)
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.
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.
ASSIGNED status
A specific software maintainer has been assigned to handle this bug report.
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.
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.
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.
RESOLVED/WORKSFORME status
The maintainer could not reproduce your bug.
RESOLVED/OLD status
The reported version or release is out of lifecyle, or the bug is already fixed.
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.
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.
TODO: merge with page content
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.
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.
