CINXE.COM

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8"> <meta name="robots" content="index,nofollow"> <title>Bugs/Triage - Ubuntu Wiki</title> <script type="text/javascript" src="/moin_static198/common/js/common.js"></script> <script type="text/javascript">  </script> <link rel="stylesheet" type="text/css" charset="utf-8" media="all" href="/moin_static198/light/css/common.css"> <link rel="stylesheet" type="text/css" charset="utf-8" media="screen" href="/moin_static198/light/css/screen.css"> <link rel="stylesheet" type="text/css" charset="utf-8" media="print" href="/moin_static198/light/css/print.css"> <link rel="stylesheet" type="text/css" charset="utf-8" media="projection" href="/moin_static198/light/css/projection.css">   <link rel="alternate" title="Ubuntu Wiki: Bugs/Triage" href="/Bugs/Triage?diffs=1&show_att=1&action=rss_rc&unique=0&page=Bugs%2FTriage&ddiffs=1" type="application/rss+xml"> <link rel="Start" href="/Home"> <link rel="Alternate" title="Wiki Markup" href="/Bugs/Triage?action=raw"> <link rel="Alternate" media="print" title="Print View" href="/Bugs/Triage?action=print"> <link rel="Up" href="/Bugs"> <link rel="Search" href="/FindPage"> <link rel="Index" href="/TitleIndex"> <link rel="Glossary" href="/WordIndex"> <link rel="Help" href="/HelpOnFormatting"> </head> <body lang="en" dir="ltr">  <div id="wrapper" class="hfeed"> <div id="header"> <ul id="mothership"> <li> <a href="http://www.ubuntu.com/partners">Partners</a> </li> <li> <a href="http://www.ubuntu.com/support">Support</a> </li> <li> <a href="http://www.ubuntu.com/community">Community</a> </li> <li> <a href="http://www.ubuntu.com">Ubuntu.com</a> </li> </ul> <div id="orangeHeader"> <h1> <a href="/" title="Ubuntu Wiki">Ubuntu Wiki</a> </h1> <div id="search-box"> <form id="searchform" method="get" action="/Bugs/Triage"> <div> <input type="hidden" name="action" value="fullsearch"> <input type="hidden" name="context" value="180"> <label for="searchinput">Search:</label> <input id="searchinput" type="text" name="value" value="" size="20" onfocus="searchFocus(this)" onblur="searchBlur(this)" onkeyup="searchChange(this)" onchange="searchChange(this)" alt="Search"> <input id="titlesearch" name="titlesearch" type="submit" value="Titles" alt="Search Titles"> <input id="fullsearch" name="fullsearch" type="submit" value="Text" alt="Search Full Text"> </div> </form> <script type="text/javascript">  </script> </div> </div> </div> <div id="wikinav"> <ul class="editbar"><li>Immutable Page</li><li><a class="nbinfo" href="/Bugs/Triage?action=info" rel="nofollow">Info</a></li><li><a class="nbattachments" href="/Bugs/Triage?action=AttachFile" rel="nofollow">Attachments</a></li><li> <form class="actionsmenu" method="GET" action="/Bugs/Triage"> <div> <label>More Actions:</label> <select name="action" onchange="if ((this.selectedIndex != 0) && (this.options[this.selectedIndex].disabled == false)) { this.form.submit(); } this.selectedIndex = 0;"> <option value="raw">Raw Text</option> <option value="print">Print View</option> <option value="RenderAsDocbook">Render as Docbook</option> <option value="refresh">Delete Cache</option> <option value="show" disabled class="disabled">------------------------</option> <option value="SpellCheck">Check Spelling</option> <option value="LikePages">Like Pages</option> <option value="LocalSiteMap">Local Site Map</option> <option value="show" disabled class="disabled">------------------------</option> <option value="RenamePage" disabled class="disabled">Rename Page</option> <option value="CopyPage">Copy Page</option> <option value="DeletePage" disabled class="disabled">Delete Page</option> <option value="show" disabled class="disabled">------------------------</option> <option value="show" disabled class="disabled">Subscribe User</option> <option value="show" disabled class="disabled">------------------------</option> <option value="show" disabled class="disabled">Remove Spam</option> <option value="show" disabled class="disabled">Revert to this revision</option> <option value="PackagePages">Package Pages</option> <option value="SyncPages">Sync Pages</option> <option value="show" disabled class="disabled">------------------------</option> <option value="Load">Load</option> <option value="Save">Save</option> <option value="SlideShow">SlideShow</option> </select> <input type="submit" value="Do"> </div> <script type="text/javascript">  </script> </form> </li></ul> <ul id="username"> <li><a href="/Home">Ubuntu Wiki</a></li> <li><a href="?action=login">Login</a></li> <li><a href="/HelpContents">Help</a></li> </ul> <hr class="clearBoth" /> </div> <div id="main"> <div id="container"> <div id="content"> <h2 class="entry-title"> <a href="/Bugs/Triage">Triage</a> </h2> <div class="hentry post"> <div id="page" lang="en" dir="ltr"> <div dir="ltr" id="content" lang="en"> <div dir="ltr" id="Bugs.2FBugsHeader.content" lang="en"> <div><table style="&quot; width:95%; &quot;"><tbody><tr> <td style="&quot; width: 40px; border: none; border-top-left-radius: 6px; border-bottom-left-radius: 6px; box-shadow: 1px 1px 1px #bbb; background-color: #f7f6f5; &quot;"><img alt="reportabug.png" class="attachment" height="45" src="/Bugs/BugsHeader?action=AttachFile&do=get&target=reportabug.png" title="reportabug.png" /></td> <td style="&quot; width: 25%; border: none; border-top-right-radius: 6px; border-bottom-right-radius: 6px; box-shadow: 1px 1px 1px #bbb; font-size: 0.90em; background-color: #f7f6f5; &quot;"><a href="/Bugs/ReportingBugs">Report a bug</a></td> <td style="&quot; border:none&quot;"></td> <td style="&quot; width: 40px; border: none; border-top-left-radius: 6px; border-bottom-left-radius: 6px; box-shadow: 1px 1px 1px #bbb; background-color: #f7f6f5; &quot;"><img alt="bugsquad.png" class="attachment" height="45" src="/Bugs/BugsHeader?action=AttachFile&do=get&target=bugsquad.png" title="bugsquad.png" /></td> <td style="&quot; width: 25%; border: none; border-top-right-radius: 6px; border-bottom-right-radius: 6px; box-shadow: 1px 1px 1px #bbb; font-size: 0.90em; background-color: #f7f6f5; &quot;"><a href="/Bugs/Triage">Triage a bug</a></td> <td style="&quot; border:none&quot;"></td> <td style="&quot; width: 40px; border: none; border-top-left-radius: 6px; border-bottom-left-radius: 6px; box-shadow: 1px 1px 1px #bbb; background-color: #f7f6f5; &quot;"><img alt="fixabug.png" class="attachment" height="45" src="/Bugs/BugsHeader?action=AttachFile&do=get&target=fixabug.png" title="fixabug.png" /></td> <td style="&quot; width: 25%; border: none; border-top-right-radius: 6px; border-bottom-right-radius: 6px; box-shadow: 1px 1px 1px #bbb; font-size: 0.90em; background-color: #f7f6f5; &quot;"><a href="/Bugs/HowToFix">Fix a bug</a></td> <td style="&quot; border:none&quot;"></td> <td style="&quot; width: 40px; border: none; border-top-left-radius: 6px; border-bottom-left-radius: 6px; box-shadow: 1px 1px 1px #bbb; background-color: #f7f6f5; &quot;"><img alt="events.png" class="attachment" height="45" src="/Bugs/BugsHeader?action=AttachFile&do=get&target=events.png" title="events.png" /></td> <td style="&quot; width: 25%; border: none; border-top-right-radius: 6px; border-bottom-right-radius: 6px; box-shadow: 1px 1px 1px #bbb; font-size: 0.90em; background-color: #f7f6f5; &quot;"><a href="/Bugs/Events">Events</a> </td> </tr> </tbody></table></div></div> <hr class="hr1" /> <img alt="Wink ;)" height="16" src="/moin_static198/light/img/icon_wink.png" title="Wink ;)" width="16" /> You can practise this concepts in a safe environment with trivial bugs by joining the <a class="https" href="https://launchpad.net/hundredpapercuts">One Hundred Papercuts</a> project. <h2 id="Introduction">Introduction</h2> <div><table style="&quot; float:right; text-align:left; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 0 0; &quot;"><tbody><tr> <td style="&quot; padding:0.5em; &quot;"><div class="table-of-contents">Contents<ol><li><ol><li> <a href="#Introduction">Introduction</a></li><li> <a href="#Bug_types">Bug types</a><ol><li> <a href="#Apport_reports">Apport reports</a><ol><li> <a href="#Apport_crash_reports">Apport crash reports</a></li></ol></li><li> <a href="#Confirmed_bugs">Confirmed bugs</a></li><li> <a href="#Feature_requests">Feature requests</a></li><li> <a href="#Regressions">Regressions</a></li><li> <a href="#Untriaged_bugs">Untriaged bugs</a></li><li> <a href="#Bug_reports_not_in_English">Bug reports not in English</a></li><li> <a href="#Special_types_of_bugs">Special types of bugs</a><ol><li> <a href="#Developer_Process_Bugs">Developer Process Bugs</a></li><li> <a href="#needs-packaging_bugs">needs-packaging bugs</a></li><li> <a href="#Security_bugs">Security bugs</a></li><li> <a href="#Translation_bugs_and_Launchpad_integration">Translation bugs and Launchpad integration</a></li></ol></li></ol></li><li> <a href="#Actions">Actions</a><ol><li> <a href="#Confirming">Confirming</a></li><li> <a href="#Forwarding_upstream">Forwarding upstream</a><ol><li> <a href="#Marking_a_bug_as_requiring_forwarding">Marking a bug as requiring forwarding</a></li></ol></li><li> <a href="#Marking_duplicate">Marking duplicate</a></li></ol></li></ol></li><li> <a href="#Bugs.2FResponses.Not_described_well">Not described well</a></li><li> <a href="#Bugs.2FResponses.Missing_Steps_to_Recreate_Bug">Missing Steps to Recreate Bug</a></li><li> <a href="#Bugs.2FResponses.Missing_Apport_Information">Missing Apport Information</a></li><li> <a href="#Bugs.2FResponses.Package_or_domain_specific_questions">Package or domain specific questions</a><ol><li><ol><li> <a href="#Improving_a_bug_report">Improving a bug report</a></li><li> <a href="#Converting_a_bug_report_to_a_question">Converting a bug report to a question</a></li><li> <a href="#Invalidating">Invalidating</a></li></ol></li><li> <a href="#Status_and_importance">Status and importance</a></li><li> <a href="#Looking_through_your_bugs">Looking through your bugs</a></li></ol></li></ol></div></td> </tr> </tbody></table></div>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 because we assess bugs to determine whether or not they have enough information to be worked on and assign a priority to them as soon as possible. Without any risk of death. This page explains the different aspects of triaging. Ubuntu receives an incredibly large number of bug reports every day through our <a class="https" href="https://bugs.launchpad.net/">bug tracking system</a>. 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 <a href="/HelpingWithBugs">HelpingWithBugs</a>. For a visual representation of the bug triage process, see these nice <a href="/Bugs/Triage/Charts">Flow Charts</a>. 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. Working on simple, untriaged bugs is a good way to get started and become acquainted with the triaging procedure since you'll have to deal with every aspect of the life cycle of a bug. The section <a class="https" href="https://wiki.ubuntu.com/Bugs/HowToTriage#Untriaged_bugs">Untriaged bugs</a> explains where to find them. <h2 id="Bug_types">Bug types</h2> <h3 id="Apport_reports">Apport reports</h3> <a href="/Apport">Apport</a> reports are bugs reported via the automated bug reporting program Apport. Reporting bugs using Apport is the preferred way of reporting a bug since it gives the developers a lot of information about the affected system. When Apport is used, less additional information is required, speeding up the whole process. You can recognize these bugs by the added list of system information in their description. Some programs have hooks for Apport, adding more information when reporting a bug. This information can usually be found in the attachments. <h4 id="Apport_crash_reports">Apport crash reports</h4> A considerable number of bugs reported by Apport concern program crashes which are reported semi-automatically and get pre-processed automatically by 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. However, this created a privacy problem since core dumps and stack traces could potentially contain sensitive information. Also, crash reports generate a lot of bug mail noise. With the automatic duplicate checking, a fair amount of the reported bugs are completely irrelevant for triagers. Since Gutsy, these problems <a href="/CrashReporting">have been mitigated</a>: bugs are filed with the "private" flag enabled, i. e. only the reporter and subscribers can see it. The reprocessing bots will subscribe the <tt class="backtick">ubuntu-bugcontrol</tt> 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: <ul><li>If the crash still has a <tt class="backtick">CoreDump.gz</tt> 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 <a class="https" href="https://bugs.launchpad.net/ubuntu/+bugs?field.tag=apport-failed-retrace">apport-failed-retrace</a>. If the stack trace looks good enough, the <tt class="backtick">CoreDump.gz</tt> attachment should be removed with the (edit) link in the attachment box. If the retrace failed completely, mark the bug as 'Invalid' and ask the reporter to refile the bug if the crash can be reproduced. Never mark a bug containing a Coredump.gz attachment as public. </li><li class="gap">If there is no <tt class="backtick">Stacktrace.txt (retraced)</tt> attachment, then the most probable reason is that the <tt class="backtick">CoreDump.gz</tt> attachment is broken. Please check with Martin Pitt (<tt class="backtick">pitti</tt> in IRC, <tt class="backtick">martin.pitt@ubuntu.com</tt>) about the reason since he can look into log files. </li><li class="gap">Check if any of stacktrace attachments (original stacktraces, <tt class="backtick">Stacktrace.txt (retraced)</tt> and <tt class="backtick">ThreadStacktrace.txt (retraced)</tt>) have anything that looks like sensitive data passed as function arguments. Examples are passwords, things that look like bank account numbers, CSS keys, user names, server names, 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. </li></ul>Except for those privacy issues, crash reports should be handled like normal bugs in terms of duplicate searching/marking, upstream forwarding, etc. <h3 id="Confirmed_bugs">Confirmed bugs</h3> When a bug is marked as 'Confirmed' it is not fully triaged yet. This bug is very close to being marked as 'Triaged', but you need to make sure it is ready for the developers to fix. If the bug adheres to ALL of the following criteria it can be considered triaged: <ul><li>Does the bug report describe a valid bug? </li><li>Does the bug report contain <a class="https" href="https://wiki.ubuntu.com/Bugs/HowToTriage#Improving_a_bug_report">enough details</a>? </li><li>If the bug is trivial to fix, is it <a href="/One%20Hundred%20Papercuts/Triage/Classify%20as%20a%20papercut">marked as affecting</a> the "hundredpapercuts" project? </li><li>If bugs for the packaged are managed elsewhere, is the bug report <a class="https" href="https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding_upstream">forwarded upstream</a>? </li><li>Is the bug report ready to be worked on by a developer? </li></ul>Only if ALL of these conditions are satisfied, you can set the status of the bug report to 'Triaged'. To do this: <ul><li>Change the "Status" field to "Triaged". </li><li>If not done yet, assign the appropriate <a href="/Bugs/Importance">importance</a>. </li><li>Click "Save changes". </li></ul>In order to set bug statuses to 'Triaged' you need to be a member of the <a href="/UbuntuBugControl">Ubuntu Bug Control</a> team. If you are not a Bug Control member, and you find a bug you believe is ready to be marked as Triaged, then please join the #ubuntu-bugs channel on irc.freenode.net and provide a link to the report. A Bug Control member can then examine the report and, if it is ready, mark it as Triaged for you. <h3 id="Feature_requests">Feature requests</h3> If the bug report is actually a feature request, there are two possibilities. If the requested enhancement is small and well-defined and/or the suggestion concerns an upstream project, the Importance of the bug should be set to 'Wishlist'. When the report is complete the status should be set to 'Triaged'. Only the members of the <a class="https" href="https://launchpad.net/~ubuntu-bugcontrol">Ubuntu Bug Control</a> team can do so. If you're not a member you'll have to ask someone who is to do it for you. Paste the bug number in #ubuntu-bugs and say you think the bug should be set to 'Wishlist'. Someone will notice and set it for you, although not necessarily immediately. Bugs requesting a feature concerning upstream projects should be forwarded upstream. Forwarding upstream is explained at <a href="/Bugs/HowToTriage#Forwarding_upstream">Forwarding Bugs Upstream</a>. However, if the request is abstract and/or suggesting a large change the bug should be closed as 'Invalid' while posting a message pointing the user to the appropriate upstream or to the user forums. A canned response you can use is: <div><table style="&quot; background-color: #eee&quot;"><tbody><tr> <td> 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 discuss the idea with other Ubuntu community members in the many public forums. Public discussion of ideas improves the likelihood of adoption. Thanks for taking the time to share your opinion!</td> </tr> </tbody></table></div> <h3 id="Regressions">Regressions</h3> A regression is a bug introduced after an update. These kind of bugs are especially important because if something breaks that used to work it interferes with the workflows of software users. These can be more obvious and painful for users than bugs. To make keeping track of regressions easier we use tags. Please make sure to use the tags when doing Triage. <div dir="ltr" id="QATeam.2FRegressionTracking.2FTable.content" lang="en"> <div><table><tbody><tr> <td> regression-release </td> <td> A regression in a new stable release or a development release. This may be a bug in a single package or functionality lost when changing the default application. </td> </tr> <tr> <td> regression-update </td> <td> A regression introduced by an updated package in the stable release. </td> </tr> <tr> <td> regression-proposed </td> <td> A regression introduced by a package in -proposed </td> </tr> <tr> <td> regression-retracer </td> <td> Used by the retracer when it finds a bug that has a similar trace to a previously closed bug. </td> </tr> </tbody></table></div></div> Once tagged, the bugs will appear on the <a class="http" href="http://qa.ubuntu.com/reports/regression/regression_tracker.html">regression tracking page</a> and will from there be escalated to the development teams. See <a href="/QATeam/RegressionTracking">QATeam/RegressionTracking</a> for more information. <h3 id="Untriaged_bugs">Untriaged bugs</h3> Untriaged bugs are bugs that haven鈥檛 been touched by any triager yet. These bugs were reported and have yet to be touched since. There are several ways to find these untouched bugs. The most commonly used method is using the <a class="https" href="https://bugs.launchpad.net/">BugTrackingSystem</a> Launchpad's search functionality; you can use Advanced search to find New bugs for a specific package. Go to the source package's bugs advanced search page and look for: <ul><li>Status: New </li><li>Importance: Undecided </li><li>Assigned to: Nobody </li></ul>All <a class="https" href="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</a> can be found via this link. Once a bug's status is no longer New it will no longer show up in this search. If you want to be notified of new bugs there are several methods to do so: <ul><li>Add the <a class="http" href="http://feeds.launchpad.net/ubuntu/latest-bugs.atom">Launchpad Atom feed for new Ubuntu bugs</a> to your feed aggregator </li><li>Join the #ubuntu-bugs-announce <a href="/InternetRelayChat">InternetRelayChat</a> channel on irc.freenode.net. </li><li>Subscribe to the <a class="https" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs">https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs</a> <a href="/MailingList">mailing list</a> [Warning: this is a high volume list that will quickly fill up your mailbox]. </li></ul>To start, just pick one of the recent ones and open the link in your favorite browser. Try to pick bugs that affect software or parts of the system 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 this bug could be yours! <h3 id="Bug_reports_not_in_English">Bug reports not in English</h3> Bug reports should be in English as that is the most commonly used language by Ubuntu developers and bug triagers. In the event that a bug report is not received in English ask the reporter to translate their bug and any error messages that are not in English. In the event that you are concerned that the bug report is critical and needs to be translated quickly e-mail the Ubuntu translators <a class="https" href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators">mailing list</a> for help in getting the bug translated. <h3 id="Special_types_of_bugs">Special types of bugs</h3> Most bugs are code or packaging defects, but some groups within Ubuntu 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 different meanings for the statuses. They may even have different meanings depending on where Ubuntu is in its release cycle. <div><table><tbody><tr> <td style="background-color: &quot;#fce94f&quot"> <img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> Unless a triager is familiar with the specific process in question, adjustments to these bugs are likely to be problematic.</td> </tr> </tbody></table></div> <h4 id="Developer_Process_Bugs">Developer Process Bugs</h4> You should generally not change bugs of this type unless working with a developer/packager. <ul><li style="list-style-type:none">Bugs in this category can have subjects like: <ul><li>Please merge <package> from Debian unstable (main) </li><li>Please sync <package> from Debian unstable (main) </li><li>Please remove <package> from the Ubuntu archives </li><li>Please promote <package> to <component> </li><li>Please demote <package> to <component> </li><li>Main inclusion report (MIR) </li></ul>Bugs in this category will have any of the following teams subscribed: <ul><li><a class="https" href="https://bugs.launchpad.net/~ubuntu-sponsors/">Ubuntu Sponsors</a> </li><li><a class="https" href="https://bugs.launchpad.net/~ubuntu-archive">Ubuntu Package Archive Administrators</a> </li><li><a class="https" href="https://bugs.launchpad.net/~motu-release">MOTU Release Team</a> </li><li><a class="https" href="https://bugs.launchpad.net/~ubuntu-release">Ubuntu Release Team</a> </li><li><a class="https" href="https://bugs.launchpad.net/~ubuntu-mir">MIR approval team</a> </li></ul></li></ul>For packages in Universe/Multiverse, please see <a href="/MOTU/Sponsorship/SponsorsQueue">Sponsors Queue</a> page for more details. <h4 id="needs-packaging_bugs">needs-packaging bugs</h4> A needs-packaging bug 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: <tt>[needs-packaging] <package></tt>, 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: <ul><li>read and follow the instructions on <a href="/MOTU/Sponsorship/SponsorsQueue">SponsorQueue</a>. A summary follows: </li><li>check to see if it is already in Ubuntu (see <a class="http" href="http://packages.ubuntu.com">http://packages.ubuntu.com</a>, or run <tt>rmadison <package></tt>): if it is already in the archives, then mark it as Invalid, and add a comment explaining your action; </li><li>if not in Ubuntu, then check Debian (see <a class="http" href="http://packages.debian.org">http://packages.debian.org</a>, or run <tt>rmadison -u debian <package></tt>). If it is in Debian, mark it as Invalid, and add a comment stating: </li></ul><pre>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.</pre><ul><li>now check <a class="http" href="http://bugs.debian.org">the Debian bug tracker</a> or <a class="http" href="http://www.debian.org/devel/wnpp/">Work-Needing and Prospective Packages</a> for an ITP (Intent To Package) or RFP (Request For Package) for this package. If you find one such request, please add an upstream bug watch for it, and continue on </li><li>now check for the upstream licenses. If license info and upstream URL are included, add a comment with the license types and the links to them upstream; if not, and you cannot find them, please add a request for the reporter to link the licenses in; </li><li>now, mark the bug as 'Triaged', and add the tag 'needs-packaging' to it. </li></ul><img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> Note: Not all package names are intuitive! Also use package descriptions to help guide you. <img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> Note 2: Never set these bugs to 'Confirmed', unless you are working with a package maintainer, and have been asked to do so. <img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> Note 3 The bug should remain on 'New', or 'Incomplete' status until all prerequisites are completed. <ul><li style="list-style-type:none">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 irc.freenode.net. </li></ul> <h4 id="Security_bugs">Security bugs</h4> The <a href="/SecurityTeam">SecurityTeam</a> uses a similar but slightly different process for Triaging bugs. If you think a bug may be a security issue or are triaging a bug flagged as a security issue, please be sure to read <a href="/SecurityTeam/BugTriage">SecurityTeam/BugTriage</a> before proceeding. <h4 id="Translation_bugs_and_Launchpad_integration">Translation bugs and Launchpad integration</h4> The Ubuntu <a href="/Translations">Translations</a> team has a separate Launchpad project for keeping track of all translation bugs. Launchpad integration is also tracked by this project. All translation and Launchpad integration bugs should have a task against the <a class="https" href="https://launchpad.net/ubuntu-translations">ubuntu-translations</a> project. If a translation bug doesn't have such a task, add one: <ol type="1"><li>Click on the 'Also affects project' link, which can be above the bug description; </li><li>If necessary click the 'Choose another project' link between the parentheses after the project name, when that project name is not Ubuntu Translations; </li><li>Enter 'ubuntu-translations' in the project name box and press 'Continue'; </li></ol>If the bug is a translation error, the 'ubuntu-translations' task should be assigned to the proper translation team; ubuntu-l10n-LC, where LC should be replaced with the language code according to the ISO 639-2 standard, or ISO 639-3 for languages that are not in the previous standard. The wiki page <a href="/Translations/KnowledgeBase/HandlingBugs">Translations/KnowledgeBase/HandlingBugs</a> contains a detailed overview of the bug policy of the <a href="/Translations">Translations</a> team. Apart from opening the 'ubuntu-translations' task to let the <a href="/Translations">Translations</a> team know the bug exists the bug should be handled like any bug. When its status in the 'ubuntu' project is <a href="/Bugs/Triage#Confirmed_bugs">set to 'Triaged'</a> they know the report is ready for them to work on. <h2 id="Actions">Actions</h2> Below are some common actions you will perform while Triaging. The <a class="https" href="https://launchpad.net/launchpad-gm-scripts">Launchpad Greasemonkey scripts</a> can be a great time-saver while performing the below actions! <img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> Please note that some teams have their own policies on triaging, see: <ul><li><a href="/Kernel/BugTriage">Kernel/BugTriage</a> </li><li><a href="/X/Triaging">X/Triaging</a> </li></ul><img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> Please note that some packages have additional policies on triaging beyond the standard processes, see: <ul><li><a class="https" href="https://wiki.ubuntu.com/ServerTeam/NGINX#BugTriage">ServerTeam/NGINX</a> </li></ul> <h3 id="Confirming">Confirming</h3> The 'Confirmed' status is used when it is certain the bug exists. If the bug adheres to ANY of the following criteria it can be considered confirmed: <ul><li>Is there a patch that claims to fix the bug? </li><li>Are there sufficient log files and crash dumps, as outlined in <a href="/DebuggingProcedures">DebuggingProcedures</a>? </li><li>Can you reproduce the bug yourself? </li><li>Does another distribution have a complete and confirmed bug? </li><li>Does the upstream author have a complete and confirmed bug? </li></ul>If ANY of these conditions are satisfied and you are not the original reporter, you can Confirm the report. To do this: <ul><li>Change the "Status" field to "Confirmed". </li><li>Assign the appropriate <a href="/Bugs/Importance">importance</a>. </li><li>Click "Save changes". </li></ul>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 developers will look at confirmed bugs first. The 'Triaged' status is used to show you are done with triaging the bug. Only members of the Ubuntu Bug Control team can set this status. Only set this status if the cause of the bug has been found and the developers can start fixing the problem right away. <h3 id="Forwarding_upstream">Forwarding upstream</h3> Forwarding bugs upstream is an important part of being a triager. Without telling them, upstream developers might never know of the bug you've been triaging so studiously. Bugs should be forward upstream when: <ul><li>the Ubuntu bug is Confirmed or Triaged, and </li><li>the issue is not due to packaging or a Debian/Ubuntu patch. </li></ul>Please keep in mind that you will be representing Ubuntu upstream. Try to leave a good impression. A good practice is to mention the original reporter of the bug and provide a link to the original bug report. It's often greatly appreciated if you link to the most important attachments and explain what they are. Before writing a whole new bug report you should look for the problem you're reporting to prevent duplicates. If you find a duplicate leave a comment mentioning the Ubuntu bug and link to it. When there are no duplicates to be found you can create a new one. Now you should link the upstream bug to the Ubuntu bug in Launchpad so we can keep track of its status. To do this: <ul><li>Click "Also affects project" </li><li>If necessary, search for and pick the right project </li><li>Choose the "I have the URL for the upstream bug:" option and paste the URL for the upstream bug in the appropriate field </li><li>Click "Add to Bug Report" </li></ul>Launchpad tracks the upstream bug and warns the subscribers to the Ubuntu bug when the status upstream has been changed. The page <a href="/Bugs/Upstream">Bugs/Upstream</a> provides more details on how to report bugs in various upstream bug trackers. <h4 id="Marking_a_bug_as_requiring_forwarding">Marking a bug as requiring forwarding</h4> 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 needing to be forwarded. To do this: <ul><li>Open an upstream task (you click on "Also affects project"), but do not assign a bug watch by selecting the option "I just want to register that it is upstream right now; I don't have any way to link it." and press "Add to Bug Report". (Mind the wording, there is a bug filed against LP <a class="https" href="https://bugs.edge.launchpad.net/launchpad/+bug/353097">bug #353097</a>) </li><li>This will mark the bug as "needs forwarding" </li><li>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. </li></ul> <h3 id="Marking_duplicate">Marking duplicate</h3> Many of the reports filed against 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: <ul><li>Click the "List open bugs" link at the bottom of the bug page or </li><li>Click the "Bugs" tab at the top of the page <ul><li>Both ways will produce a list of bugs about the same package </li></ul></li><li>Look for bugs with similar descriptions or related titles. </li><li>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. </li><li>For the other report, add a comment like this standard reply Include: Nothing found for "^== A duplicate ==$"!<div dir="ltr" id="Bugs.2FResponses.content" lang="en"> <div dir="ltr" id="BugSquad.2FKBHeader.content" lang="en"> <div><table style="&quot; width:90%; &quot;"><tbody><tr> <td style="&quot; border: 1px solid #E6E5E4; background-color: #F7F6F5; text-align: center; &quot;"><img alt="information_little.png" class="attachment" src="/BugSquad/KBHeader?action=AttachFile&do=get&target=information_little.png" title="information_little.png" width="20px" /> This page is part of the <a href="/BugSquad">Bug Squad鈥檚</a> <a href="/BugSquad/KnowledgeBase">KnowledgeBase</a> - pages with information about how to triage bugs. </td> </tr> </tbody></table></div></div> These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at: <a class="https" href="https://launchpad.net/~gm-dev-launchpad/+archive/ppa">https://launchpad.net/~gm-dev-launchpad/+archive/ppa</a> 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 <a class="https" href="https://code.launchpad.net/ubuntu-bugcontrol-tools">lp:ubuntu-bugcontrol-tools</a> in the file <a class="http" href="http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-bugcontrol-tools/trunk/view/head:/gm-xml-files/bugsquad-replies.xml">gm-xml-files/bugsquad-replies.xml</a>. To check out a branch, use <pre>bzr branch lp:ubuntu-bugcontrol-tools</pre>Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see <a class="https" href="https://lists.ubuntu.com/archives/ubuntu-bugsquad/2010-November/002833.html">this email message</a>), and they can be used when replying to a bug report if merged. <div class="table-of-contents">Contents<ol><li> <a href="#Bugs.2FResponses.Not_described_well">Not described well</a></li><li> <a href="#Bugs.2FResponses.Missing_Steps_to_Recreate_Bug">Missing Steps to Recreate Bug</a></li><li> <a href="#Bugs.2FResponses.Missing_Apport_Information">Missing Apport Information</a></li><li> <a href="#Bugs.2FResponses.Package_or_domain_specific_questions">Package or domain specific questions</a></li></ol></div> <h1 id="Bugs.2FResponses.Not_described_well">Not described well</h1> <div><table style="&quot; background-color: #eee&quot;"><tbody><tr> <td>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" <a class="http" href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">http://www.chiark.greenend.org.uk/~sgtatham/bugs.html</a>. 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 <a class="http" href="http://wiki.ubuntu.com/DebuggingProcedures">http://wiki.ubuntu.com/DebuggingProcedures</a>. 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! </td> </tr> </tbody></table></div> <h1 id="Bugs.2FResponses.Missing_Steps_to_Recreate_Bug">Missing Steps to Recreate Bug</h1> <div><table style="&quot; background-color: #eee&quot;"><tbody><tr> <td>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.</td> </tr> </tbody></table></div> <h1 id="Bugs.2FResponses.Missing_Apport_Information">Missing Apport Information</h1> <div><table style="&quot; background-color: #eee&quot;"><tbody><tr> <td>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 <a class="https" href="https://wiki.ubuntu.com/ReportingBugs">https://wiki.ubuntu.com/ReportingBugs</a>.</td> </tr> </tbody></table></div> <h1 id="Bugs.2FResponses.Package_or_domain_specific_questions">Package or domain specific questions</h1> The following packages or type of bugs require the specific debugging information: </div> </li><li>Then click the "Mark as Duplicate" link at the top right of the bug report page, and enter the number of the primary bug. </li></ul>By default, searches in Launchpad and mentioned above will only look at <tt>Open</tt> bugs. It may also be worthwhile to go through the list of <tt>Invalid</tt> and <tt>Won't Fix</tt> bugs which you can look for by using an "Advanced Search". There is also a standardized tag for bugs likely to have lots of duplicates -- <a class="https" href="https://launchpad.net/ubuntu/+bugs?field.tag=metabug">metabug</a>. When marking a bug report as a duplicate of another (master) bug report, please also check whether the master bug report is marked as 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 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 a master bug and marking another bug as a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs). For more information on private Apport bugs, have a look at the <a href="/Bugs/HowToTriage#Apport_crash_reports">Apport crash reports</a> section. <h3 id="Improving_a_bug_report">Improving a bug report</h3> Only valid and well described bugs can be processed efficiently and swiftly by the developers. A small guide at <a href="/Bugs/Improving">Bugs/Improving</a> helps with handing over a good bug to the developers when setting the status 'Triaged'. <h3 id="Converting_a_bug_report_to_a_question">Converting a bug report to a question</h3> Some bug reporters aren't actually reporting a bug but rather are looking for support with using Ubuntu. These bug reports should be converted to questions so that they will appear in the Launchpad answer tracker and can be answered there. Telling whether or not a bug report is actually a support request is subjective but these guidelines may help you determine which is which. <ol type="1"><li>Is the reporter looking for help to accomplish a task? <ul><li>Installing printer drivers for a printer is a good example of this </li></ul></li><li class="gap">Is the reporter missing a package to accomplish a task? <ul><li>Missing codecs to watch DVDs is a good example of this </li></ul></li><li class="gap">Is the bug report in a foreign language? </li><li class="gap">Has the reporter misconfigured their system? <ul><li>Mangled lines in <tt>/etc/apt/sources.list</tt> </li></ul></li></ol> <h3 id="Invalidating">Invalidating</h3> 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. <img alt="Warning /!\" height="16" src="/moin_static198/light/img/icon_eek.png" title="Warning /!\" width="16" /> 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 do not need to invalidate these bugs -- bugs in incomplete status without a response will be automatically expired in 60 days. For the other (i.e., those not waiting for a response from the reporter), the best thing to do here is to politely decline the report while thanking the user for submitting it. There are some useful <a href="/Bugs/Responses">Bugs/Responses</a> 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. <h2 id="Status_and_importance">Status and importance</h2> The default meanings of <a href="/Bugs/Importance">importances</a> and Statuses are explained at <a href="/Bugs/Importance">importance</a> and <a href="/Bugs/Status">Bugs/Status</a>. Make sure you've read these pages thoroughly. 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. <h2 id="Looking_through_your_bugs">Looking through your bugs</h2> Perhaps you want to look at a list of bugs you are working on to see if anyone has replied and to make sure you haven't forgotten one. 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: <ul><li style="list-style-type:none"><a class="https" href="https://bugs.launchpad.net/people/+me/">https://bugs.launchpad.net/people/+me/</a> </li></ul>You can see you subscribed bugs at <a class="https" href="https://bugs.launchpad.net/~/+subscribedbugs">https://bugs.launchpad.net/~/+subscribedbugs</a>, or the bugs you've commented on at <a class="https" href="https://bugs.launchpad.net/~/+commentedbugs">https://bugs.launchpad.net/~/+commentedbugs</a>. 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 anything. 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. <hr /> Go back to <a href="/HelpingWithBugs">HelpingWithBugs</a>. <a href="/CategoryBugSquad">CategoryBugSquad</a> </div>  <div id="pagebottom"></div> </div> <div class="entry-utility"> Bugs/Triage (last edited 2017-02-14 00:06:22 by <a class="interwiki" href="https://launchpad.net/~teward" title="teward @ localhost[127.0.0.1]">teward</a>) </div> </div> </div> </div> <div class="clearBoth"></div> </div> </div> <div id="footer"> <div id="siteinfo"> The material on this wiki is available under a free license, see <a href="https://help.ubuntu.com/community/License">Copyright / License</a> for details. </div> </div> <script> (function(i,s,o,g,r,a,m){ i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m) })(window,document,'script','//www.google-analytics.com/analytics.js','ga'); ga('create', 'UA-1018242-7', 'auto'); ga('send', 'pageview'); </script></body> </html>