Development/Howto/Bugzilla
From Mandriva Community Wiki
This page contains information on the correct procedure to follow in filing a bug report against a Mandriva Linux distribution. Please read it and follow it when filing bugs: it will help us to increase the efficiency of the bug resolution process.
Contents |
[edit] Bug tracking system
There is one central place for reporting Mandriva bugs: http://qa.mandriva.com. It uses the popular open source bug tracking system called Bugzilla.
[edit] Before you submit a new bug
First, you will need a Bugzilla account. Bugzilla does not use the my.mandriva accounts used by several other Mandriva services. You can register for an account on the Bugzilla front page.
Next, try and determine whether you really should report the issue. First, check whether it's already been reported by someone else.
[edit] Search Bugzilla
Search Bugzilla to ensure that there is no similar problem already reported, and that the problem is still outstanding.
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.
Also look at the Errata page for the Mandriva Linux release you are using, and check if the issue is listed there.
If you find 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.
[edit] Use the latest package
Next, ensure you are using the latest version of the package available. If you are using Cooker, you should already know how to keep your system up to date. If you are using a stable release, follow the instructions at Installing updates to ensure your system is up to date, then make sure the problem still occurs before filing a bug.
[edit] Is it appropriate?
Next, check that the issue you're reporting is one which should be handled via the Mandriva bug resolution system. There are two types of issues which can appropriately be handled here. The first is cases where a component of a Mandriva Linux distribution fails to perform as intended in a way which can be most effectively resolved by the Mandriva development team. The second is enhancement requests relating to applications developed by the Mandriva development team, or relating to the packaging of other applications.
Problems which would better be handled elsewhere - for instance, by the original developers of an application - should not be reported to the Mandriva bug resolution system. Neither should enhancement requests relating to applications not developed by the Mandriva development team: these should be sent to the appropriate developers.
[edit] Is it supported?
All bug reports should be made against supported releases. The lifetime map lists the support lifetime of all currently supported releases. If a release is not listed here, it is no longer supported. Bug reports filed against products which are no longer supported are very unlikely to be resolved.
[edit] Submitting a new bug report
If you have done searches to assure yourself that your bug report is the first one on this topic, please post enough information:
[edit] Correct distribution
Choosing the correct Distribution (release) 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.
Note that all snapshot, alpha, beta and RC releases count as Cooker releases. Bugs in these releases should be filed against the Cooker Distribution. Please also state in the report exactly which release you are using.
[edit] Correct product, component, version
You should attempt to select the correct product, component and version for the bug.
- 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-file
- more RPM package info is available using: rpm -qi package-name
If you cannot identify which package a bug should be reported against, please do not let this prevent you from filing the bug. Make your best guess, and include a note in the description of the bug stating that you are not sure whether it is filed against the correct product. The triage team will help ensure the product is correct before passing the bug on to the package maintainer.
[edit] Details
Details are important. When in doubt, provide more rather than less information.
- find the RPM version of software: rpm -q package-name
- describe your hardware if this may be a hardware-related problem:
- 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
- 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 reliably cause the problem to occur
- include information about any configuration changes you have made
When a bug report is filed without sufficient information being provided, the triage team will set its status to NEEDINFO and post a comment on the bug explaining what further information is required. Please ensure that, if this happens to a bug you file, you provide the requested information.
[edit] 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. It is generally preferred that configuration files of any significant length be posted as attachments, as this makes them easier to handle.
[edit] After your bug is submitted
Once your bug is submitted, it will be handled according to the bug policy. In brief, this means a member of the triage team will decide whether or not it is a valid report that requires the attention of a maintainer. If they decide that it is, they will ensure the report is sufficiently detailed, requesting further information from you (the reporter) where necessary. The bug will then be assigned to the appropriate maintainer for resolution.
[edit] Solve your own problem
By all means, try to solve your own problem and fix the bug! A 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).
