Ubuntu Wiki

Overview

TableOfContents

The proper source package

Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in Ubuntu. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to Ubuntu.

The correct package for bugs in the Linux kernel is linux, regardless of which particular package is in use (there are many packages which contain Linux kernels).

Confirming problems

If a bug is marked as Unconfirmed, it is helpful for you to try to reproduce the problem, and record the results in Malone. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment.

Forwarding bugs upstream

You can forward bugs to the authors of the software (upstream), if

• you made sure that the bug doesn't occur because of Ubuntu related changes,
• the change is too hard to be fixed by yourself or anyone else in the team.

If you do this, be sure to

• include all the necessary information, such as
  • how to reproduce the bug
  • which version is used (which version of dependent libraries, if the bug indicates problems there)
  • who reported it
  • where the whole conversation can be found
• create a bug watch in Malone for this

How to Deal with Feature Requests

If you feel that the bug reported is a feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, ["SpecTemplate"] and http://launchpad.net/specs

How to deal with Support Requests

If you feel that the bug reported is a support request disguised as a bug report, please introduce the reporter gently to the Support Tracker we have. Be sure to mention http://launchpad.net/support

How to deal with suggestions for changing defaults

If you feel that the bug reported is a suggestions for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments.

Finding Duplicates

Finding duplicates of bugs is a very valuable contribution in the Bug community. Users sometimes don't know how to check if the same bug has already been filed, and sometimes they don't care. Weeding out simple ME TOO messages and aggregating information in one place is crucial to the process of fixing a bug.

There are quite a few measures you can take to assist with this aspect, one way is to search for bugs filed for the same component, also try to rephrase your search, and concentrate on actions and words that describe the items involved to reproduce this crash.

Examples:

• Easy ones:

  • [http://bugzilla.ubuntu.com/show_bug.cgi?id=18808 DAAP support] is a duplicate of

    • [http://bugzilla.ubuntu.com/show_bug.cgi?id=18733 please enable daap]

• More difficult ones:

  • [http://bugzilla.ubuntu.com/show_bug.cgi?id=17858 plug:spdif on emu10k1 gone after breezy upgrade] is a duplicate of

    • [http://bugzilla.ubuntu.com/show_bug.cgi?id=15585 Muted sound after dist-upgrade from Hoary to Breezy]

If you can't find it in the list of open bugs, you could try to find it in the list of closed ones. Don't feel discouraged, if you don't find duplicates fast in the beginning, after some time you will get to know the usual suspects, and learn how to more easily identify them.

Note: If you encounter a bug that has a terrible / unintelligible title, rephrase it, so people find it more easily.

Reminder of the Code of Conduct

Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please direct them to http://www.ubuntulinux.org/community/conduct/document_view

Managing Severity

Ubuntu uses the following guidelines for assigning severity:

• Wishlist: a request to add a new feature to one of the programs in Ubuntu. Use this for bugs which aren't really bugs, but ideas for new features which do not yet exist

• Minor: Bugs which affect functionality, but to a lesser extent than most bugs

• Normal: A functionality bug of the standard variety. Most bugs are of "Normal" severity.

• Major: A bug which fulfills one of the following criteria:

  • Has a severe impact on a small portion of Ubuntu users (estimated)
  • Has a moderate impact on a large portion of Ubuntu users (estimated)

• Critical: A bug which has a severe impact on a large portion of Ubuntu users

Back to HelpingWithBugs