Duplicates

Many of the reports filed about Ubuntu are actually duplicates of bugs already reported. This can happen after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, reporters don't know how to check if the same bug has already been filed, or it is hard for them to determine if their bug is the same as another. Finding these duplicate bugs and aggregating information in one bug report is a very valuable contribution.

Bugs are duplicates when they have the same root cause. Determining this is a skill that you'll pick up as you become more familiar with a particular package or subsystem. Bugs are not necessarily duplicates if they have the same effects. For example, many different bugs can cause X not to start. Determining which bug a particular report refers to is part of triaging. If in doubt, ask for a second opinion. It is probably also sensible to ask the reporter to take look at the possible duplicate and to help with the decision. Reporters are normally interested in helping with their own bug reports!

When you first look at a new bug, try to find an existing bug in the system that describes the new one. Here's how:

Kernel Team policy requires that only a kernel maintainer can set a kernel bug as a duplicate of another bug. See the kernel policy for details.

• Click the "List open bugs" link at the bottom of the bug page or

• Click the "Bugs" tab at the top of the page
  • Both ways will produce a list of bugs about the same package
• Look for bugs with similar descriptions or related titles.
• If they describe the same root cause, decide which report should be the primary one. This should be the one that's the most understandable and contains the most information, not necessarily the oldest (lowest numbered) bug.

• For the other report, add a comment like this standard reply

  Include: Nothing found for "^== A duplicate ==$"!

  This page is part of the Bug Squad’s KnowledgeBase - pages with information about how to triage bugs.

  These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at:

  https://launchpad.net/~gm-dev-launchpad/+archive/ppa

  When you update one of these responses, you should also update the response used by the Firefox extension. These responses can be found in the bazaar branch lp:ubuntu-bugcontrol-tools in the file gm-xml-files/bugsquad-replies.xml. To check out a branch, use

  bzr branch lp:ubuntu-bugcontrol-tools

  Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see this email message), and they can be used when replying to a bug report if merged.

  Contents

  1. Not described well
  2. Missing Steps to Recreate Bug
  3. Missing Apport Information
  4. Package or domain specific questions

  Not described well

  Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem. We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures. At a minimum, we need: 1. The specific steps or actions you took that caused you to encounter the problem. 2. The behavior you expected. 3. The behavior you actually encountered (in as much detail as possible). Please also ensure that you include the release and flavour of Ubuntu that you are using. Thank you!

  Missing Steps to Recreate Bug

  Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions: * Is this reproducible? * If so, what specific steps should we take to recreate this bug? This will help us to find and resolve the problem.

  Missing Apport Information

  Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal: apport-collect BUGNUMBER When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

  Package or domain specific questions

  The following packages or type of bugs require the specific debugging information:

• Then click the "Mark as Duplicate" link at the top left of the bug report page, and enter the number of the primary bug.

The default searches in Launchpad and used above will only look at Open bugs. It may also be worthwhile to go through the list of Invalid and Won't Fix bugs which you can look for by using the Advanced search. There is also a standardized bug tag for ones likely to have lots of duplicates - metabug.

When marking a bug report as a duplicate of another (master) bug report, please also check whether the master bug report is marked as a private. If so, the master bug report might not be visible to the current bug reporter. When the parent bug is indeed marked as private please check why it is so. If it's only private because apport makes all bugs private by default, but the coredump has been removed and none of the apport attachments contain anything private, it may be made public. If it does contain confidential information, the bug should remain as private and it is better to search for another bug which could be safely marked as the master bug. For any guidance regarding the private status of master bug and marking another bug a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs).

CategoryBugSquad