Projects/Bugs/Triage guide
From Mandriva Community Wiki
This page is a guide to triaging bugs reported on Mandriva Linux. It is intended principally for members of the Bug Squad and should serve as a guide for new members and an aide memoire for experienced members.
[edit] Is it on Mandriva Linux?
Please work only on bugs filed on Mandriva Linux, the mainline distribution. Our project is not concerned with bugs filed on the Corporate products (Multi Network Firewall, Corporate Server, and Corporate Desktop). If you come across a bug filed on one of these products, please just leave it as it is.
[edit] Is it a duplicate?
The first thing to consider is whether the bug is a duplicate of a previously-opened bug. You may simply remember from previous work that you have seen the bug report before. Otherwise, run the following checks to try and find a duplicate report:
- Search all bugs on the distribution component in question
- Search all bugs on similar or related components where a duplicate bug may also be filed
- Search the entire database using the name of the affected component
- Search the entire database using keywords related to the bug that are most likely to return duplicate bugs
Consider the relationships between components when searching. For instance, if someone reports a crash in a GNOME application, consider that the underlying problem may in fact lie in, for instance, the GTK+ or Pango libraries. Search in these areas.
Important: otherwise identical bugs filed on different distributions should not be closed as duplicates. For instance, if a bug is reported on Cooker and then subsequently on a stable release, do not close the second report as a duplicate of the first. The reason for this is that resolution of a bug in one distribution does not imply resolution of the same bug in another distribution, so under the current Bugzilla system, having separate reports for each distribution is the best way to handle such situations.
If the bug is a duplicate of a previous report, you should set the bug to the RESOLVED DUPLICATE status with the appropriate bug number. This will usually be the only action required. If the fact that the bug is a duplicate may not be obvious to the reporter without further explanation - for instance, the report is for a crash in a certain program, but the problem actually lies in an underlying library and has been previously reported - you may wish to explain this in a comment to ensure the reporter understands the resolution.
[edit] Is it an issue that should be covered by the Mandriva bug process?
Firstly, consider the definition of a bug from the Bug Policy: "A bug is defined as a case in which a component of a Mandriva Linux distribution (or other product covered by Bugzilla, such as a Mandriva web site) fails to fulfill its intended function." Consider whether the issue reported qualifies under these terms. Note that there is an exception for valid enhancement requests - see the Bug Policy for more details. An example of a report which would fail this test is a request for an additional feature in a piece of software which is not maintained by the Mandriva Linux development team, or a report which is obviously attributable not to a Mandriva Linux component but to user error or to a hardware issue with the reporter's computer.
If a bug fails this test, you should set the bug to the RESOLVED INVALID status and provide an explanation of your reasoning in a comment.
Secondly, consider the case that the bug may be better handled elsewhere (usually by the developers of the software in question). For instance, a bug caused by a fundamental flaw in the software's source code should be resolved by the upstream development team, even though it could theoretically be fixed by a Mandriva developer with a patch. Resolving such issues upstream reduces the burden of patch maintenance on the Mandriva development team (and the associated risk of error and instability).
If a stack trace is provided in the bug report, consider searching the upstream bug management system (for instance, GNOME or KDE Bugzilla) to see if a bug with a similar strack trace has previously been reported.
This is an area which will require you to use your judgment wisely. For instance, where a problem lies in the software itself, but the required fix is likely trivial, you should generally consider the bug to be appropriate for the Mandriva process; in this case the issue will be temporarily fixed by a Mandriva patch which will also be submitted to the upstream developers, and removed when it is merged into the upstream version of the software. You must also take into account the upstream maintenance status of the software. If the code is not being maintained upstream, or is only being maintained very sporadically, the situation changes. In this case, even if the issue is a significant one in the actual code of the package and you would normally consider it to be more appropriate for the upstream development team, you may wish to consider it appropriate for the Mandriva process as there is a higher likelihood that the Mandriva development team will be able to resolve it than that the inactive upstream maintainers will.
If you determine that it would be more appropriate for the issue to be resolved by the upstream development team, you should post a comment explaining your reasoning and requesting that the reporter of the bug send a report to the appropriate place (depending on the package, this may be another bug tracking system, a forum, or a mailing list). Ideally, include a link to the appropriate place in your comment, for the reporter's convenience. Ask the reporter to post a comment once he has made his upstream report, linking to the report. Once the reporter has done this, you should set the bug to the RESOLVED REPORTEDUPSTREAM resolution.
In the case of bugs reported on stable releases, this may not be the final resolution to the problem. Once the bug has been fixed by the upstream development team, it may be appropriate to re-open the Mandriva report in order for the fix to be incorporated with an update to the Mandriva package.
Thirdly, consider whether the bug is filed on a supported Mandriva Linux release. If the release on which the bug is filed is no longer supported, set it to the RESOLVED OLD resolution with a comment explaining the reason.
[edit] Has all necessary information been provided by the reporter?
If the issue passes these tests, it is an issue requiring action by the maintainer, and should eventually be assigned to the maintainer for action. However, you should not do this until the information provided on the issue is as complete as possible.
The general rule is that a bug report should contain at least enough information to make the problem simple for the maintainer to reproduce and understand. Valuable information includes, but is not limited to:
- Exact version of the package(s) being used
- Architecture (i586 or x86-64)
- Precise steps to reproduce the problem ("gedit crashes" is bad; "gedit crashes when I launch it from the menu, type 'abracadabra' and click on Print" is good)
- Error messages displayed by the application, or on a console when the application is run from the console
- Hardware information where this may be a factor - IDE / SCSI / SATA hard disks, USB storage devices, lsusb, lspci, lspcidrake etc output...
- Information on the operating environment: what desktop / shell is in use, is the app being run remotely, what other packages which may affect operation of the app are in use, what configuration settings have been changed
A very good way to check whether all necessary information has been provided is to see whether you can reproduce the issue yourself using the information provided in the bug report. Triage team members are advised to keep copies of all currently supported Mandriva Linux releases available to help with this. You may want to consider using VMware, VirtualBox, qemu etc for this purpose.
If sufficient information has not yet been provided, you should add the NEEDINFO keyword to the bug, and add a comment explaining to the reporter what further information is required and - if necessary - how to obtain it.
[edit] Special cases of specific information required
Here are some specific types of bug for which certain types of information will always be required:
[edit] Installer-related bugs
For bugs related to the traditional installer, DrakX (i.e. Free or Powerpack installation, not One), the reporter should provide the file /root/drakx/report.bug.gz as an attachment.
[edit] Hardware detection issues, hardware not supported
If a piece of hardware is detected wrong or does not seem to be supported at all, the output of the command lspcidrake -v (and lsusb for USB devices) is required. If not supported at all, it would also help to know if the reporter is aware of a driver that could potentially support the device.
[edit] Problems with HDA audio chipsets
There are several dozen (even hundreds) of slightly differing implementations of the Intel HDA audio codec, all supported by the snd-intel-hda driver. If someone is having a problem related to sound which appears to involve this driver, the contents of the file /proc/asound/card0/codec#0 is required. If this file doesn't exist, check for common variations (different card or codec number).
[edit] initrd-related bugs
initrd-related bugs can be easily mistaken for kernel bugs, so take care to correctly identify these bugs. If a bug is initrd-related, the package field should be set to mkinitrd and the bug assigned to Luca Bera (bluca AT comedia DOT it). The information specified here is also required.
[edit] Set the product priority, severity and component fields
It is your responsibility as a triage team member to set the product, priority, severity and component fields appropriately.
Product is simply the product line in which a bug falls. The majority of bugs will use Mandriva Linux. Triage team members should ignore bugs with the Product set to any of the three Corporate products (Server, Desktop and Multi Network Firewall).
For Component:
- Core Packages - packages in /main
- Other Packages - packages in /contrib
- Package Request - used for both requests for a new app to be packaged and requests for version bumps for existing ones
- Release Media - issues with discs, ISOs or on the mirrors
Other options are self-explanatory.
For Priority:
The release_critical priority is only relevant to bugs filed on Cooker or beta releases, and should only be used for issues which are sufficiently critical that it would severely impair the overall quality of a release if it were made available without the issue being resolved. The high priority should be used for issues which are sufficiently critical that resolving them should take priority over resolving other issues, but which do not meet the criteria for release_critical. The low priority should be used for bugs which are sufficiently trivial and/or limited in impact that resolving other issues should take precedence. The normal priority should be used for all other issues.
For Severity:
The critical severity should be used for bugs which render a package essentially unusable (for instance, crashes which would affect the majority of uses of a package, or total inability to install or run the package). The major severity should be used for issues which render a significant feature of the package unusable, or which render the package generally unstable. The minor severity should be used for issues which have only a limited impact on the usability of a package or which will only affect a small minority of users or use cases, and the trivial severity should be used for issues which have almost no material impact on the usability of a package. The normal severity should be used for all other issues.
You should also set the RPM Package field where it has not been filled out by the reporter, and where you know what it should be set to. This field can be changed in the block of options below the Comment field.
[edit] Accept bug and ensure bug is assigned to the correct maintainer
If the bug has made it this far, you can now accept the bug: set the status to ASSIGNED, using the ACCEPTED standard response, and add the Triaged keyword. You should also check that it is assigned to the correct maintainer. In most cases the assignment will be correct, but sometimes the Bugzilla maintainer database is incorrect and a bug will be assigned to the wrong person. You can use the rpmmon utility to tell you who the maintainer is: rpmmon -p packagename. If you suspect it may be wrong, check the last few changelog entries for the package. If you are not sure to whom the bug should be assigned, make a best guess, favoring maintainers who are quick to respond to Bugzilla issues.
[edit] Dependency issues
If the bug is that a package cannot be installed due to dependency issues, please mark it as blocking Bug #30890. This is a tracker bug for dependency issues.
[edit] Enhancement requests
Valid enhancement requests are requests to do with the packaging of a product, or requests for improvements in the code of applications maintained by the Mandriva development team. To handle enhancement requests, check whether the report is a duplicate, then check whether the request is comprehensible as written. If not, set the report to NEEDINFO and ask the reporter to clarify. Once the report is sufficiently comprehensible, set the severity to enhancement and the priority to normal and assign the bug to the package maintainer.
