Triage

Differences between revisions 1 and 102 (spanning 101 versions)
Revision 1 as of 2006-10-05 19:26:01
Size: 7135
Editor: 206-248-163-14
Comment:
Revision 102 as of 2009-08-25 23:49:24
Size: 16707
Editor: ua-178
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
<<Include(Bugs/BugsHeader)>>

||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>||
Line 3: Line 7:
Bug triage is a lot like that. Without any risk of death. Bug triage is a lot like that as we assess bugs to determine whether or not they have enough to be worked on and assign a priority to them as soon as possible. Without any risk of death.
Line 5: Line 9:
Ubuntu receives an incredibly large number of bug reports every day through our BugTrackingSystem. Each one of these needs to be read, accessed, and sorted before being fixed. This is where we could use your assistance with HelpingWithBugs. Ubuntu receives an incredibly large number of bug reports every day through our [[https://bugs.launchpad.net/ | bug tracking system]]. Each one of these needs to be read, assessed, and sorted so it can be fixed. This is where we could use your assistance with HelpingWithBugs. For a visual representation of the bug triage process, see these nice [[Bugs/HowToTriage/Charts|Flow Charts]].
Line 7: Line 11:
== New bugs == = Untriaged bugs =
Line 9: Line 13:
Every bug report is a conversation with the reporter. The first contact any reporter usually has with Ubuntu is through a bug triager, who tries to put together a complete bug report. It's fairly important that we give a good impression, so please be polite and try to use your best English. [[https://launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-datecreated&field.status%3Alist=Unconfirmed&field.importance%3Alist=Undecided&assignee_option=none&field.assignee=&field.owner=&field.component=1&field.component=2&field.component-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_no_package.used=&search=Search|Untriaged bugs]] can be found via this link. Once a bug's status is no longer '''New''' it will no longer show up in this search.
Line 11: Line 15:
In order to help triage bugs, you have to be able to find them. Fortunately, this is easy. You can find out about new reports in one of two ways: You can use the '''Advanced search''' in the [[https://bugs.launchpad.net/|BugTrackingSystem]] to find '''New''' bugs for a specific package. Go to the source package's bugs advanced search page and look for:
 * '''Status:''' New
 * '''Importance:''' Undecided
 * '''Assigned to:''' Nobody
Line 13: Line 20:
 * Join the #ubuntu-bugs InternetRelayChat channel on irc.freenode.net.
 * Subscribe to the ubuntu-bugs@lists.ubuntu.com MailingList.
= New bugs =
Line 16: Line 22:
The first method is far more preferable, as you won't get a mailbox stuffed full of mail each time you read it. I tried the second option for a while and couldn't keep up at all. Every bug report is a conversation with the reporter. The first contact any reporter usually has with the Ubuntu community is through a bug triager, who tries to put together a complete bug report. It's very important that we give a good impression, so please be polite and try to use your best English.
Line 18: Line 24:
When you enter #ubuntu-bugs, you'll soon see the following types of messages fly by: In order to help triage bugs, you have to be able to find them. Fortunately, this is easy. You can find out about new reports in one of three ways:

 * Add the [[http://feeds.launchpad.net/ubuntu/latest-bugs.atom|Launchpad Atom feed for new Ubuntu bugs]] to your feed aggregator
 * Join the #ubuntu-bugs-announce InternetRelayChat channel on irc.freenode.net.
 * Subscribe to the https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs [[MailingList|mailing list]] [This is a high volume list].

The first method is far more preferable, as you won't get a mailbox stuffed full of mail each time you read it. I tried the third option for a while and couldn't keep up at all.

If you enter #ubuntu-bugs-announce, you'll soon see the following types of messages fly by:
Line 21: Line 35:
New bug: #1 in Ubuntu "Microsoft has a majority market share" [Undecided,Unconfirmed] http://launchpad.net/bugs/1 New bug: #1 in Ubuntu "Microsoft has a majority market share" [Undecided,New] http://launchpad.net/bugs/1
Line 24: Line 38:
To start, just pick one of the recent ones and open the link in your favourite browser. If no one else has commented yet, then this bug could be yours! To start, just pick one of the recent ones and open the link in your favourite browser. Try to pick bugs which affect software or parts of the system that you are familiar with yourself, as this will help you decide how complete the report is, and make it easier for you to reach the grail of reproducing the bug. If no one else has commented yet, then this bug could be yours!
Line 26: Line 40:
== Duplicates == <<Include(Bugs/MarkingDuplicate)>>
Line 28: Line 42:
Many of the reports filed against Ubuntu are actually duplicates of known reports. This usually happens after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, users will file a report that duplicates an older bug, but has different symptoms. = Apport crash reports =
Line 30: Line 44:
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 program or package. Bugs are ''not'' necessarily duplicates if they have the same effects. If in doubt, ask for another opinion. A considerable number of bugs concern program crashes which are reported semiautomatically with [[https://wiki.ubuntu.com/Apport|Apport]] and get pre-processed automatically by some bots in the Canonical data center. These bots try to generate a fully symbolic stack trace and check for duplicates.
Line 32: Line 46:
When you first look at a new bug, try to find an existing bug in the system that describes this one. Here's how: In Feisty and early Gutsy, those bugs were public, so that everyone could see them. This created a privacy problem, though, since core dumps and stack traces could contain potentially sensitive information. Also, crash reports generate a lot of bug email noise. With the automatic duplicate checking, a fair amount of the reported bugs are completely irrelevant for triagers.
Line 34: Line 48:
 * On the right-hand side of the page, click the "Show all open bugs" link.
 * Look for bugs with similar descriptions or related topics.
 * If they describe the same root cause, decide which report should be the primary one. This should be the one that's clearest.
 * For the other report, click the "Mark as Duplicate" link on the left-hand side of the page.
In current Gutsy, these problems [[https://wiki.ubuntu.com/CrashReporting|have been mitigated]]: bugs are filed with the "private" flag enabled, i. e. only the reporter and subscribers can see it. The reprocessing bots will subscribe the `ubuntu-bugcontrol` team, but without sending bug email to the team members.
Line 39: Line 50:
== Complete reports == Thus crash bugs differ from other bugs in two important aspects: they need to be checked for sensitive data, and there will not be any initial bug mail for them until they become public. Triagers should check the following things:
Line 41: Line 52:
We want to make sure that every triaged bug is complete before it gets examined by someone who will fix it. When a bug is complete, it's much easier to isolate the cause of the problem and write a fix. Which means more bugs get fixed faster.  * If the crash still has a `CoreDump.gz` attachment, then it was not possible to automatically get a fully symbolic stack trace and check for duplicates. In this case, the bug will be tagged with [[https://bugs.launchpad.net/ubuntu/+bugs?field.tag=apport-failed-retrace|apport-failed-retrace]]. If the stack trace looks good enough, the `CoreDump.gz` attachment should be removed with the (edit) link in the attachment box. If the retrace failed completely, just leave the bug alone.
Line 43: Line 54:
A complete bug report must contain the following things:  * If there is no `Stacktrace.txt (retraced)` attachment, then the most probable reason is that the `CoreDump.gz` attachment is broken. Please check with Martin Pitt (`pitti` in IRC, `martin.pitt@ubuntu.com`) about the reason, he can look into log files.
Line 45: Line 56:
 * The steps the user performed to produce the problem.
 * The expected result of these actions.
 * The actual result of these actions.
 * The version of Ubuntu the user is running.
 * Check if the `Stacktrace.txt (retraced)` attachment has anything that looks like sensitive data passed as function arguments. Examples are passwords, things that look like bank account numbers, CSS keys, etc. If you don't find anything, you may mark the bug as public ("This report is public/private" in the top right of the bug report). This is not required, though, it is fine to keep the bug private throughout its lifetime.
Line 50: Line 58:
As a triager, you'll learn to ask for additional information when it's relevant. For instance: Except for those privacy issues, crash reports should be handled like normal bugs in terms of duplicate searching/marking, upstream forwarding, etc.
Line 52: Line 60:
 * The version numbers of the affected programs.
 * Any crash dumps produced by these programs.
 * [:Backtrace]s and other debugging output.
 * Any log files that are related to the problem.
<<Include(Bugs/Improving)>>
Line 57: Line 62:
Our DebuggingProcedures can tell you what extra information should be included for particular classes of bugs. = Confirming =
Line 59: Line 64:
Since most reports probably won't be complete, you'll have to start a conversation. Ask the reporter for more information like so:

 * Click on the task name, which is usually the package name.
 * Change the "Status" field to "Needs Info".
 * Select "Me" for the "Assigned to" field.
 * Check "E-mail me about changes to this bug report".
 * Ask for more information in the "Comment on this change" field.
 * Click "Save changes".

You assign this report to yourself so you know which conversations you're having. And you subscribe to this bug so you will be e-mailed when the reporter responds.

== Confirming ==

When you have a complete report, and there is enough information to debug the program, you can confirm the report. How do you know there is enough information? Here are some example criteria, any of which is sufficient:
When you have a complete report, and there is enough information to debug the program, you can confirm the report. How do you know there is enough information? Here are some example criteria, there is no order to these criteria and you can do them in the order of your preference, '''ANY''' of which is sufficient:
Line 80: Line 72:
If any of these conditions are satisfied, you can Confirm the report. To do this: If '''ANY''' of these conditions are satisfied, you can Confirm the report. To do this:
Line 83: Line 75:
 * Assign the appropriate "Importance" value, according to [["Bugs/Importance"]].
 * Select "Nobody" for the "Assigned to" field.
 * Assign the appropriate "Importance" value, according to [[Bugs/Importance]].
 * Change the "Assigned to" field to "Nobody".
Line 87: Line 79:
== Forwarding upstream == Do not be worried if a bug you have confirmed, which cannot be sent upstream stays "confirmed" for a very long time. Ubuntu has many, many bugs and the devs will look at confirmed bugs first.
Line 89: Line 81:
Much of the software in Ubuntu is not actually written by us. We package many pieces of free and open source software, collect them in a distribution, and integrate them. As such, many bugs are actually in programs we've never written. = Status and Importance =
Line 91: Line 83:
In order to be good citizens, we want to forward good bug reports to the original (or upstream) authors. This helps the author track down bugs in their software. And it helps Ubuntu when they fix the bug. If in doubt, the maintainer (or the one working on the bug) should change the Status and Importance. It usually reflects the status of this work or reflects how the bug fits into her/his working time.
Line 93: Line 85:
Forwarding a bug is a bit of work, but it's well worth it. Here's what you do: Please check [[Bugs/Importance]] and see [[Bugs/Status]].
Line 95: Line 87:
 * Find the upstream author.
 * If they have a bug tracking system,
  * Sign up for it, if necessary.
  * Search for this bug report in the upstream system.
  * If it doesn't exist, report a new bug in their system.
  * Link their bug report to ours.
 * If they have a mailing list or e-mail address,
  * Report the bug by sending an e-mail to the appropriate address.
= Forwarding upstream =
Line 104: Line 89:
When you report a new bug, please include the following information: <<Include(Bugs/Upstream)>>
Line 106: Line 91:
 * Link to the bug inside Malone, in the form: https://launchpad.net/bugs/######
 * Credit the initial reporter.
 * Provide a complete description of the problem.
== Marking a Bug as Requiring Forwarding ==
Line 110: Line 93:
Linking a bug report is much easier: If you find a bug that needs forwarding, it is best to forward it immediately. However, if you are running short on time, you can still mark the bug as requiring to be forwarded. To do this:
 
 * Open an upstream task (you click on "Also affects project"), but do not assign a bug watch (after the page with "Record as affecting another project" on the page with "Confirm project", you click on the "I just want to register that it is upstream right now; I don't have any way to link it."). Mind the wording (there is a bug filled against LP [[https://bugs.edge.launchpad.net/launchpad/+bug/353097|bug #353097]])
 * This will mark the bug as "needs forwarding"
 * You can search for those bugs in the "Advanced Search" by selecting the "Show only bugs that need to be forwarded to an upstream bugtracker" option.
Line 112: Line 99:
 * Click the "+ Upstream..." or "+ Distribution..." link, as appropriate.
 * Choose the correct "Product" or "Distribution".
 * Check the "Link to a bug in another bug tracker:" box.
 * Select the proper "Remote Bug Tracker".
 * Enter the bug identification number in the "Remote Bug" field.
 * Click "Continue".
= Invalidating =
Line 119: Line 101:
== Rejecting == Sometimes, you will have to invalidate a bug report. This may be because the problem is not reproducible, or the program was designed to behave a certain way.
Line 121: Line 103:
Sometimes, you will have to reject a bug report. This may be because the problem is not reproducible, the program was designed to behave a certain way, or the report is actually a feature request. There will be a few bug reporters who never get back to you and there is not enough information for the bug to be worked on. You will want to mark those bugs also as Invalid.
Line 123: Line 105:
The best thing to do here is to politely decline the report while thanking the user for submitting it. There are some useful ["Bugs/Responses"] that you can use in these cases. The best thing to do here is to politely decline the report while thanking the user for submitting it. There are some useful [[Bugs/Responses]] that you can use in these cases.

There is no need to reject bugs that are '''already''' marked as a duplicate of another bug. Doing so creates bug mail noise as every subscriber of the duplicate bug and the master bug will receive e-mail that the status of the bug changed from something to Invalid.

<<Include(Bugs/Responses, , from="^== Incomplete bugs without a response from submitter ==", to="==")>>

= Feature Requests =

If the report is actually a feature, the Importance of the bug should be set to 'Wishlist' by someone in the 'Bug Control' group. Paste the bug # in #ubuntu-bugs and say that you think the bug should be set to 'wishlist'. Someone will notice and set it for you although not necessarily immediately.

Most of them should be forwarded to the upstream developers, for instructions on how to do it please have a look to [[Bugs/HowToTriage#Forwarding%20upstream|Forwarding Bugs Upsteam]]

= An idea to improve Ubuntu =

 Note: If it is a request to add a feature to a '''specific program''' it should be '''forwarded to the upstream developers instead.''' See: [[Bugs/HowToTriage#Forwarding%20upstream|Forwarding Bugs Upsteam]]

Not everybody requesting an improvement should be directed to brainstorm. Only larger things, or instances where it would be good to get the feedback of users, such as changing a default program. If you redirect the reporter to brainstorm, please close the bug as Invalid, adding the following comment:

||<tablestyle="background-color: #eee"> Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at http://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion! ||

= Regressions =

It is especially important that we catch bug reports concerning regressions and bring them to the attention of the developers. This includes regressions in current stable releases, in updates, in the proposed queue or potential regressions in the next release. These should be labeled with the following tags respectively: '''regression-release''', '''regression-update''', '''regression-proposed''' and '''regression-potential'''.

Once tagged, the bugs will appear on the [[http://qa.ubuntu.com/reports/regression/regression_tracker.html|regression tracking page]] and will from there be escalated to the development teams. See [[QATeam/RegressionTracking]] for more information.

= Special types of bugs =

Not all bugs are the same. Most bugs are code or packaging defects, but some groups also use bugs for other things. Careful attention must be paid to these bugs so as not to disrupt team processes. These classes of bugs have special rules and meanings for different statuses. They may even have different meanings depending on where Ubuntu is in its release cycle. Unless a triager is familiar with the specific process in question, adjustments to these bugs are likely to be problematic.

== Developer Process Bugs ==

You should generally not change bugs of this type unless working with a developer/packager.
 
 Bugs in this category can have subjects like:
  * Please merge <package> from Debian unstable (main)
  * Please sync <package> from Debian unstable (main)
  * Please remove <package> from the Ubuntu archives
  * Please promote <package> to <component>
  * Please demote <package> to <component>
  * Main inclusion report (MIR)
  
 Bugs in this category will have '''any''' of the following teams subscribed:
  * [[https://bugs.launchpad.net/~ubuntu-universe-sponsors/|Ubuntu Universe Sponsors]]
  * [[https://bugs.launchpad.net/~ubuntu-main-sponsors/|Ubuntu Main Sponsors]]
  * [[https://bugs.launchpad.net/~ubuntu-archive|Ubuntu Package Archive Administrators]]
  * [[https://bugs.launchpad.net/~motu-release|MOTU Release Team]]
  * [[https://bugs.launchpad.net/~ubuntu-release|Ubuntu Release Team]]
  * [[https://bugs.launchpad.net/~ubuntu-mir|MIR approval team]]

For packages in Universe/Multiverse, please see [[https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue|Sponsors Queue]] page for more details.

== Needs Packaging Bugs ==

A ''needs-packaging'' is, a subset of the Developer Process bugs above: it is not really a bug, but a request to add a new package to Ubuntu. You may find them with a subject like: {{{[needs-packaging] <package>}}}, or with either the description or summary requesting that a package be created. These bugs are used to track software requested for inclusion in Ubuntu. For these bugs, please:

  * read and follow the instructions on [[https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue|SponsorQueue]]. A summary follows:
  * '''check''' to see if it is already in Ubuntu (see http://packages.ubuntu.com, or run {{{rmadison <package>}}}): if it is already in the archives, then mark it as ''Invalid'', and add a comment as to why;
  * if '''not''' in Ubuntu, then check Debian (see http://packages.debian.org, or run {{{rmadison -u debian <package>}}}). If it is in Debian, mark it as ''Invalid'', and add a comment stating:
{{{
Packages for this software appear to exist in Debian already. Ubuntu has semi-automatic tools to sync new packages from Debian so it will most likely appear in the next Ubuntu release.
}}}
  * now check [[http://bugs.debian.org|the Debian bug tracker]] or [[http://www.debian.org/devel/wnpp/|Work-Needing and Prospective Packages]] for an ITP ('''I'''ntent '''T'''o '''P'''ackage) request for this package. If you find one such request, please add an upstream bug watch for it, and continue on;
  * now check for the upstream licences. If license info and upstream url are included, add a comment with the licence types and the links to them upstream; if not, and you cannot find them, please add a request for the reporter to link the licences in;
  * now, mark the bug as 'Triaged', and add the tag 'needs-packaging' to it.

/!\ ''Note:'' not all package names are intuitive! Also use package descriptions to help guide you.

/!\ ''Note 2:'' '''Never''' set these bugs to 'Confirmed', unless you are working with a package maintainer, and have been asked to do so.

/!\ ''Note 3'' The bug should remain on 'New', or 'Incomplete' status until all requisites are completed.

 If you are unsure as to whether the bug that you are looking at fits in one of these categories, feel free to ask in #ubuntu-bugs or #ubuntu-motu on Freenode.

== Security Bugs ==
The SecurityTeam uses a similar but slightly different process for Triaging bugs. If you think this may be a security bug or are triaging a bug flagged as security, please be sure to read [[SecurityTeam/BugTriage|SecurityTeam/BugTriage]] before proceeding.

= Looking through your bugs =

Perhaps you want to look at a list of bugs you are working on, to see if anyone has replied.

A good way to get a list of these bugs is to look at your related bugs. This can be found in your "Bugs" page at Launchpad:
 [[https://bugs.launchpad.net/people/+me/]]
You can see you subscribed bugs at [[https://bugs.launchpad.net/people/+me/+subscribedbugs]], or the bugs you've commented on at [[https://bugs.launchpad.net/people/+me/+commentedbugs]]. Links to both are available at your main "Bugs" page.

You should go through your bugs fairly often, maybe once a week, to make sure you haven't missed any new comments or changes. This includes bugs you have reported upstream. If there is an important fact from an upstream bug you should add it to the ubuntu bug report.
Line 126: Line 193:
Go back to '''[[HelpingWithBugs]]'''.<<BR>><<BR>>

In a hospital, triage happens the instant a patient arrives through the emergency room doors. His vital signs are checked, his status assessed, and he gets sorted in amongst all the other patients waiting for treatment.

Bug triage is a lot like that as we assess bugs to determine whether or not they have enough to be worked on and assign a priority to them as soon as possible. Without any risk of death.

Ubuntu receives an incredibly large number of bug reports every day through our bug tracking system. Each one of these needs to be read, assessed, and sorted so it can be fixed. This is where we could use your assistance with HelpingWithBugs. For a visual representation of the bug triage process, see these nice Flow Charts.

Untriaged bugs

Untriaged bugs can be found via this link. Once a bug's status is no longer New it will no longer show up in this search.

You can use the Advanced search in the BugTrackingSystem to find New bugs for a specific package. Go to the source package's bugs advanced search page and look for:

  • Status: New

  • Importance: Undecided

  • Assigned to: Nobody

New bugs

Every bug report is a conversation with the reporter. The first contact any reporter usually has with the Ubuntu community is through a bug triager, who tries to put together a complete bug report. It's very important that we give a good impression, so please be polite and try to use your best English.

In order to help triage bugs, you have to be able to find them. Fortunately, this is easy. You can find out about new reports in one of three ways:

The first method is far more preferable, as you won't get a mailbox stuffed full of mail each time you read it. I tried the third option for a while and couldn't keep up at all.

If you enter #ubuntu-bugs-announce, you'll soon see the following types of messages fly by:

New bug: #1 in Ubuntu "Microsoft has a majority market share" [Undecided,New] http://launchpad.net/bugs/1

To start, just pick one of the recent ones and open the link in your favourite browser. Try to pick bugs which affect software or parts of the system that you are familiar with yourself, as this will help you decide how complete the report is, and make it easier for you to reach the grail of reproducing the bug. If no one else has commented yet, then this bug could be yours!

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

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:

Warning /!\ 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 ==$"!

    information_little.png 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.

    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

Apport crash reports

A considerable number of bugs concern program crashes which are reported semiautomatically with Apport and get pre-processed automatically by some bots in the Canonical data center. These bots try to generate a fully symbolic stack trace and check for duplicates.

In Feisty and early Gutsy, those bugs were public, so that everyone could see them. This created a privacy problem, though, since core dumps and stack traces could contain potentially sensitive information. Also, crash reports generate a lot of bug email noise. With the automatic duplicate checking, a fair amount of the reported bugs are completely irrelevant for triagers.

In current Gutsy, these problems have been mitigated: bugs are filed with the "private" flag enabled, i. e. only the reporter and subscribers can see it. The reprocessing bots will subscribe the ubuntu-bugcontrol team, but without sending bug email to the team members.

Thus crash bugs differ from other bugs in two important aspects: they need to be checked for sensitive data, and there will not be any initial bug mail for them until they become public. Triagers should check the following things:

  • If the crash still has a CoreDump.gz attachment, then it was not possible to automatically get a fully symbolic stack trace and check for duplicates. In this case, the bug will be tagged with apport-failed-retrace. If the stack trace looks good enough, the CoreDump.gz attachment should be removed with the (edit) link in the attachment box. If the retrace failed completely, just leave the bug alone.

  • If there is no Stacktrace.txt (retraced) attachment, then the most probable reason is that the CoreDump.gz attachment is broken. Please check with Martin Pitt (pitti in IRC, martin.pitt@ubuntu.com) about the reason, he can look into log files.

  • Check if the Stacktrace.txt (retraced) attachment has anything that looks like sensitive data passed as function arguments. Examples are passwords, things that look like bank account numbers, CSS keys, etc. If you don't find anything, you may mark the bug as public ("This report is public/private" in the top right of the bug report). This is not required, though, it is fine to keep the bug private throughout its lifetime.

Except for those privacy issues, crash reports should be handled like normal bugs in terms of duplicate searching/marking, upstream forwarding, etc.

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

Improving a bug report

Part of the bug triaging process involves ensuring that the bug is valid, well described, and contains adequate information for a developer to start working on it.

To be considered complete, a bug report should normally contain:

  • The version of Ubuntu that the reporter is running
  • The version of the package the reporter is using
  • The actions taken to produce the problem
  • Whether or not it is possible for the reporter to reproduce the bug
  • The expected result of these actions
  • The actual result of these actions

Not every bug reported contains all this information though. So as triagers we should ask for all of the above if they are missing. Sometimes a particular piece of information may be clear from the rest of the report, or clearly not needed for a particular report. A good test is to see if you can reproduce the bug yourself on the basis of the available information. If in doubt, it may be better to discuss with the reporter before marking the bug as incomplete.

Additionally, certain classes of bugs and specific packages require more detailed information like configuration and log files. The DebuggingProcedures page contains a list of links to detailed information to gather.

Since most reports probably won't be complete, you'll have to start a conversation with the bug reporter. Ask the reporter for more information by doing the following:

  • Click on the bug task name, which is usually the package name, in the yellow horizontal line.
  • Change the "Status" field to "Incomplete".
  • Ask for the additional information required in the "Comment on this change" field.
  • Click the "E-mail me about changes to this bug report" check box, so that you'll be subscribed to the bug
  • Click "Save changes".

As a subscriber to the bug, you will be e-mailed when the reporter responds.

Even if the bug report is complete it could probably still use some improvement.

  • Is the bug's summary descriptive of the bug? This will help people find bugs easier.
    • consider "no r5xx support in radeon driver (X1300, X1400, X1600, X1800, X1900, X1950)" vs

    • "update-manager" or "Screen Saver Issues" or "Buffer I/O Error"

Incomplete bug expiration

Ubuntu doesn't have the resources to address every bug, so we want to focus our resources on the bugs we really need to fix. Having tens of thousands of bug reports in the system which we can't and won't get to is not constructive, and it makes the bug fixing we CAN do less efficient. We focus our effort on bugs introduced in the Ubuntu packaging process, or specific to the Ubuntu versions of packages, and bugs which create very significant issues for many users. We also focus attention on bugs which are well-defined and complete, because those are the ones developers have the best chance of addressing in a reasonable time.

Also, many bugs are fixed from release to release because they are addressed in new upstream releases which get packaged for the new Ubuntu release. It can be difficult to get the attention of the bug reporter if they have upgraded to a new version. However, it is important to try and establish if an incomplete bug has been addressed in a new version.

Therefore, bugs which are marked Incomplete will eventually be "expired", and drop off the primary reporting lists for developer attention.

If a bug is not fully defined, please set it to Incomplete and ask if it is still valid. If a new release of Ubuntu has been made, it is also reasonable to ask if the bug still manifests in the new release and set the bug to Incomplete. Unless the reporter resets the bug status the bug report will be set to expire.

Confirming

When you have a complete report, and there is enough information to debug the program, you can confirm the report. How do you know there is enough information? Here are some example criteria, there is no order to these criteria and you can do them in the order of your preference, ANY of which is sufficient:

  • Is there a patch that claims to fix the bug?
  • Are there sufficient log files and crash dumps, as outlined in DebuggingProcedures?

  • Can you reproduce the bug yourself?
  • Does another distribution have a complete and confirmed bug?
  • Does the upstream author have a complete and confirmed bug?

If ANY of these conditions are satisfied, you can Confirm the report. To do this:

  • Change the "Status" field to "Confirmed".
  • Assign the appropriate "Importance" value, according to Bugs/Importance.

  • Change the "Assigned to" field to "Nobody".
  • Click "Save changes".

Do not be worried if a bug you have confirmed, which cannot be sent upstream stays "confirmed" for a very long time. Ubuntu has many, many bugs and the devs will look at confirmed bugs first.

Status and Importance

If in doubt, the maintainer (or the one working on the bug) should change the Status and Importance. It usually reflects the status of this work or reflects how the bug fits into her/his working time.

Please check Bugs/Importance and see Bugs/Status.

Forwarding upstream

Upstream Bug Resources

  • The Upstream Report - Bug linkage percentages for the top 50 projects in Ubuntu, sorted by open bugs. Please note that this report is still in Beta. Instructions for using the report.

  • Bugs that need forwarding to the Upstream bugtrackers.

  • Unlinked upstream bugs - Sometimes people add a link to an upstream bug tracker in the comments of a bug but don't bother creating an upstream task. This is a list of possible targets that can be linked. (Lots of low hanging fruit in this list, but also a bunch of dupes and ones inappropriate to be linked.)

  • How to set a bug watch

  • Why Upstream? - Thoughts from freedesktop.org on why sending things upstream is a good idea.

  • There are also some cases where you don't need to file a bug upstream, for those cases please have a look at When not to Forward a bug upstream

Upstream bug trackers

Instructions for how to file bugs in specific upstream bug trackers. (Feel free to add more!)

Marking a Bug as Requiring Forwarding

If you find a bug that needs forwarding, it is best to forward it immediately. However, if you are running short on time, you can still mark the bug as requiring to be forwarded. To do this:

  • Open an upstream task (you click on "Also affects project"), but do not assign a bug watch (after the page with "Record as affecting another project" on the page with "Confirm project", you click on the "I just want to register that it is upstream right now; I don't have any way to link it."). Mind the wording (there is a bug filled against LP bug #353097)

  • This will mark the bug as "needs forwarding"
  • You can search for those bugs in the "Advanced Search" by selecting the "Show only bugs that need to be forwarded to an upstream bugtracker" option.

Invalidating

Sometimes, you will have to invalidate a bug report. This may be because the problem is not reproducible, or the program was designed to behave a certain way.

There will be a few bug reporters who never get back to you and there is not enough information for the bug to be worked on. You will want to mark those bugs also as Invalid.

The best thing to do here is to politely decline the report while thanking the user for submitting it. There are some useful Bugs/Responses that you can use in these cases.

There is no need to reject bugs that are already marked as a duplicate of another bug. Doing so creates bug mail noise as every subscriber of the duplicate bug and the master bug will receive e-mail that the status of the bug changed from something to Invalid.

Include: Nothing found for "^== Incomplete bugs without a response from submitter =="!

information_little.png 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.

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:

Feature Requests

If the report is actually a feature, the Importance of the bug should be set to 'Wishlist' by someone in the 'Bug Control' group. Paste the bug # in #ubuntu-bugs and say that you think the bug should be set to 'wishlist'. Someone will notice and set it for you although not necessarily immediately.

Most of them should be forwarded to the upstream developers, for instructions on how to do it please have a look to Forwarding Bugs Upsteam

An idea to improve Ubuntu

  • Note: If it is a request to add a feature to a specific program it should be forwarded to the upstream developers instead. See: Forwarding Bugs Upsteam

Not everybody requesting an improvement should be directed to brainstorm. Only larger things, or instances where it would be good to get the feedback of users, such as changing a default program. If you redirect the reporter to brainstorm, please close the bug as Invalid, adding the following comment:

Thank you for taking the time to make Ubuntu better. Since what you submitted is not really a bug, or a problem, but rather an idea to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at http://brainstorm.ubuntu.com/ where it can be discussed, voted by the community and reviewed by developers. Thanks for taking the time to share your opinion!

Regressions

It is especially important that we catch bug reports concerning regressions and bring them to the attention of the developers. This includes regressions in current stable releases, in updates, in the proposed queue or potential regressions in the next release. These should be labeled with the following tags respectively: regression-release, regression-update, regression-proposed and regression-potential.

Once tagged, the bugs will appear on the regression tracking page and will from there be escalated to the development teams. See QATeam/RegressionTracking for more information.

Special types of bugs

Not all bugs are the same. Most bugs are code or packaging defects, but some groups also use bugs for other things. Careful attention must be paid to these bugs so as not to disrupt team processes. These classes of bugs have special rules and meanings for different statuses. They may even have different meanings depending on where Ubuntu is in its release cycle. Unless a triager is familiar with the specific process in question, adjustments to these bugs are likely to be problematic.

Developer Process Bugs

You should generally not change bugs of this type unless working with a developer/packager.

For packages in Universe/Multiverse, please see Sponsors Queue page for more details.

Needs Packaging Bugs

A needs-packaging is, a subset of the Developer Process bugs above: it is not really a bug, but a request to add a new package to Ubuntu. You may find them with a subject like: [needs-packaging] <package>, or with either the description or summary requesting that a package be created. These bugs are used to track software requested for inclusion in Ubuntu. For these bugs, please:

  • read and follow the instructions on SponsorQueue. A summary follows:

  • check to see if it is already in Ubuntu (see http://packages.ubuntu.com, or run rmadison <package>): if it is already in the archives, then mark it as Invalid, and add a comment as to why;

  • if not in Ubuntu, then check Debian (see http://packages.debian.org, or run rmadison -u debian <package>). If it is in Debian, mark it as Invalid, and add a comment stating:

Packages for this software appear to exist in Debian already. Ubuntu has semi-automatic tools to sync new packages from Debian so it will most likely appear in the next Ubuntu release.
  • now check the Debian bug tracker or Work-Needing and Prospective Packages for an ITP (Intent To Package) request for this package. If you find one such request, please add an upstream bug watch for it, and continue on;

  • now check for the upstream licences. If license info and upstream url are included, add a comment with the licence types and the links to them upstream; if not, and you cannot find them, please add a request for the reporter to link the licences in;
  • now, mark the bug as 'Triaged', and add the tag 'needs-packaging' to it.

Warning /!\ Note: not all package names are intuitive! Also use package descriptions to help guide you.

Warning /!\ Note 2: Never set these bugs to 'Confirmed', unless you are working with a package maintainer, and have been asked to do so.

Warning /!\ Note 3 The bug should remain on 'New', or 'Incomplete' status until all requisites are completed.

  • If you are unsure as to whether the bug that you are looking at fits in one of these categories, feel free to ask in #ubuntu-bugs or #ubuntu-motu on Freenode.

Security Bugs

The SecurityTeam uses a similar but slightly different process for Triaging bugs. If you think this may be a security bug or are triaging a bug flagged as security, please be sure to read SecurityTeam/BugTriage before proceeding.

Looking through your bugs

Perhaps you want to look at a list of bugs you are working on, to see if anyone has replied.

A good way to get a list of these bugs is to look at your related bugs. This can be found in your "Bugs" page at Launchpad:

You can see you subscribed bugs at https://bugs.launchpad.net/people/+me/+subscribedbugs, or the bugs you've commented on at https://bugs.launchpad.net/people/+me/+commentedbugs. Links to both are available at your main "Bugs" page.

You should go through your bugs fairly often, maybe once a week, to make sure you haven't missed any new comments or changes. This includes bugs you have reported upstream. If there is an important fact from an upstream bug you should add it to the ubuntu bug report.


Go back to HelpingWithBugs.

CategoryBugSquad

Bugs/Triage (last edited 2017-02-14 00:06:22 by teward)