Triage guide

From Mandriva Community Wiki

(Redirected from Projects/Bugs/Triage guide)
Jump to: navigation, search
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.


Contents

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.


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.

Caution !
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. You have to also set blockers and depends properly: cooker bug blocks other mandriva versions bugs.

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.

Exceptions

Thierry Vignaud asked us to not keep multiple bugs for the same problem opened for each affected version as he will handle updates himself when fixing the problems. Then, you can mark this kind of bug reports as duplicate if they are assigned to Thierry.


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.

Sometimes a bug report is a support issue rather than a genuine bug. In these cases, you have to close the bug report as INVALID and suggest the reporter to ask for help in http://forum.mandriva.com instead.

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 stack 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.

Tip !
An UPSTREAM keyword also exists for bugs severe enough that needs to be fixed by Mandriva even when upstream hasn't released yet a new version fixing the problem. In this case, the bug is kept opened and UPSTREAM keyword is added, letting mandriva maintainer to close it as REPORTEDUPSTREAM if he/she thinks it's better.

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, add NEEDINFO keyword and ask reporter for testing if it's still valid with latest cooker or any still supported products. If no reply is provided, you can set it to the RESOLVED OLD resolution with a comment explaining the reason after waiting more than two months. This doesn't apply to enhancement requests as most of them should be set to Cooker version (modify version field if needed).

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.

Special cases of specific information required

Here are some specific types of bug for which certain types of information will always be required:

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. An easy way for doing this is ask the reporter to switch to console 2 (use "ctrl-alt-F2") during installation, put a fat floppy in floppy drive or plug a USB key and type "bug". It will put report.bug on floppy/key.

Also, traditional installer bugs are usually assigned to Install Team. Only diskdrake crashes has to be assigned to pterjan. Bugs in Mandriva ONE installer have to be assigned to blino.

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. More extended information for these bugs can be seen here

Special (multimedia) keys not recognized

If xev output shows that keys are being recognized (keycodes are shown) but they are not working under KDE, tell reporter to run tailf ~/.xsession-errors and press affected keys. Reporter has to provide that information.

On the other hand, if keycodes are not shown when running xev, it could be a "xkeyboard-config" instead.

If xev output shows no events and messages like "atkbd.c: Unknown key pressed" are being shown, please ask for lshal output and assign it to "hal-info" package.

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 result of the command cat /proc/asound/card?/codec#? is required.

Hang when launching X

There are some cases where reporters suffer hangs just after X are started, in this case, is interesting asking them to boot with init=3 for getting a working system with console. Please visit this forum post, also bug 47989 will help us if implemented in the future.

X driver to be used can be set also as a kernel parameter while booting with xdriver=vesa (for example)

Speedboot / pinit problems

User can boot without speedboot simply using speedboot=no as boot parameter. Also ask for bootchart png file, for getting it, user simply needs to install bootchart and, then, reboot. After that, he will find png file under /var/log/

Sometimes, parallel init also causes problems (like X not starting), reporter can then try to append nopinit

Hang when using grub gfxboot / Grub problems

In some circumstances, reporter can suffer a black window just when grub starts, this can be caused by gfxboot, for booting disabling it, simply ask the user to press left shift during mandriva bootup. It will also show debugging grub information.

System not booting due to wrong menu.lst file

You have to ask reporter for attach generated /boot/grub/menu.lst file and proper menu.lst if possible. Also, reporter should provide fdisk -l /dev/sd[a-z] output for knowing more about partition table.

Printer detection problems

Maintainer put some debugs in printing packages in the past, then, it's recommended to ask for grep hal_lpadmin /var/log/{messages,syslog} just after the user has connected the printer (at least for usb ones).

For hplip related issues, please ask for hp-check -r output.

Scanner problems

The following output has to be provided in addition of general outputs: sane-find-scanner and scanimage -L

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 Kernel Team. The information specified here is also required.

Pulseaudio problems

When some reporter is suffering an issue only when pulseaudio is enabled (you should ask reporter to test without pulseaudio, it can be disabled from draksound) reporter should follow these steps: At first, he/she has to kill existing pulseaudio with "pulseaudio -k", then run pulseaudio -vvv and keep the terminal open. The debug info will flow as you use pulseaudio clients, and this is the info we are looking for.

Networking issues

They can be caused by drivers or configuration problems, then, you should ask for errors in /var/log/messages related with connection and dmesg output, that could show some issues with involved kernel modules. Also, you should ask for /etc/sysconfig/network-scripts when it seems to be a configuration problem.

Of course, ask for lspcidrake -v output and, when the issue is related to wireless, the output of iwconfig and iwlist scan are also needed.

Also, if a driver is supported by ndiswrapper, ask for ndiswrapper -l output, and with pcmcia cards, using lspcmcia.

Suspend/Hibernate issues

Always ask for dmesg output after resuming if possible, if not, ask for it anyway.

At first, we need to know if it's caused by X or not, for that, please ask user to turn X off (service dm stop), login as root and run pm-{suspend,hibernate} . If it works, it could be a X problem, then, ask reporter for /var/log/Xorg.0.log, /etc/X11/xorg.conf and lspcidrake -v output. If it still fails, ask reporter for trying to suspend/hibernate running "echo mem|disk > /sys/power/state".

Plymouth problems

It can be disabled simply appending splash=verbose as boot parameter.

Samba issues

Usually, /var/log/samba contents are useful for trying to solve samba problems

Evolution Mail Client Error

If the reporter gets: Evolution Mail Client Error - Summary and folder mismatch, even after a sync

you should ask him for quitting evolution and remove *.ev-summary* files in ~/.evolution/mail/local/

He probably has a corrupted index and evolution is not able to rebuild it correctly. This bug would be valid only if the problem reappears again just after following the procedure

Crashes

Usually, reporter will need to install additional debug packages for getting useful backtraces, they should read this at first. But there are common procedures that reporters can follow easily for crashes related to KDE,Gnome,Pulseaudio and Mandriva Tools crashes (remind the reporters to use debug repositories for their Mandriva version).

For finding duplicates related with Mandriva tools, please read this link

Perl - CPAN issues

If the user is trying to upgrade cpan modules using "cpan" the bug should be closed as INVALID because it is not the official way of doing it, since we are providing cpan modules packaged (more explanation)

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 - Use to request new packages to be added to the distribution
  • Release Media - issues with discs, ISOs or on the mirrors (mirror bugs should be assigned to distrib-admin@mandrivalinux.org instead of release)

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. Try to prevent untriaged bugs still assigned to Triage Team from being set as release_critical except they are really really severe.

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.


Exceptions

Thierry Vignaud asked Triage Team in the past to leave all bugs assigned to him with Priority and Severity set to "normal", excluding enhancement requests or really important crashes or bugs that can be set as release_critical when apropiate.


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: use the ACCEPTED standard response, and add the Triaged keyword. Bugs realated with KDE team has to be left as "NEW" and not set to "ASSIGNED", as KDE team will set them to "ASSIGNED" when actively working on them. 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.

Please note!
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.

Useful links for knowing maintainers are Mandriva Maintainers and Sophie


TRACKER bugs

Here is a list of TRACKER bugs opened for organizing problems related with some topic:

Bug #17892 : mark bugs related with "Mandrake" word still being used instead of "Mandriva" as blockers of this one.

Bug #30791 : mark bugs related with fingerprint/libfprint/thinkfinger issues as blockers of this one.

Bug #32019 : mark netprofile bugs as blockers of this one.

Bug #34492 : mark drakwizard bugs (only non-enhancement) as blockers of this one.

Bug #35933 : mark pulseaudio transition bugs as blockers of this one. This is for bugs in third party apps, not for pulseaudio own problems. For example, this is for bugs like wine not working ok with pulseaudio, but not for pulseaudio crashing.

Bug #35991 : mark texlive related bugs as blockers of this one.

Bug #39256 : PCM is used by default for setting sound volume, if it doesn't work, ask for "lspcidrake -v", "uname -a" (they need to be running latest kernel available for their distribution version) , "cat /proc/asound/version" and "cat /proc/asound/card0/codec#0" outputs and, then, mark the bug as blocker of this one.

Bug #42689 : mark EEE PC bugs as blockers of this one.

Bug #43712 : mark text mode installer bugs as blockers of this one

Bug #48658 : mark bugs related with mandriva not working ok when running from qemu/kvm as blockers of this one

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.

On the other hand, if it's an enhancement request to be done directly by upstream, you have to close the bug as INVALID and ask user to report directly to them

Most of requests will be only solved in cooker for future Mandriva releases (like installer related requests), then, you should try to set version to cooker most of times, except bugs requesting, for example, a package backport.


Common Upstream bug trackers

Personal tools