Triage
|
Size: 7135
Comment:
|
Size: 11223
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">'''Contents'''[[BR]][[TableOfContents]]|| |
|
| Line 5: | Line 7: |
| 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 BugTrackingSystem. Each one of these needs to be read, assessed, and sorted before being fixed. This is where we could use your assistance with HelpingWithBugs. |
| Line 7: | Line 9: |
| == New bugs == | = Untriaged bugs = [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 has been triaged it will no longer show up in this search. You can use the '''Advanced search''' in the BugTrackingSystem to find untriaged 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 = |
| Line 11: | Line 22: |
| 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: | 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: |
| Line 13: | Line 24: |
| * Join the #ubuntu-bugs InternetRelayChat channel on irc.freenode.net. * Subscribe to the ubuntu-bugs@lists.ubuntu.com MailingList. |
* 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. * Join the https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs MailingList [This is a high volume list]. |
| Line 16: | Line 28: |
| 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. | 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. |
| Line 18: | Line 30: |
| When you enter #ubuntu-bugs, you'll soon see the following types of messages fly by: | When you enter #ubuntu-bugs-announce, you'll soon see the following types of messages fly by: |
| Line 21: | Line 33: |
| 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 26: | Line 38: |
| == Duplicates == | [[Include(Bugs/MarkingDuplicate)]] |
| Line 28: | Line 40: |
| 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 42: |
| 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 44: |
| 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 can 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 46: |
| * 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 48: |
| == 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 50: |
| 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 52: |
| 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 54: |
| * 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 ("Visibility/security" in the top left pink box). This is not required, though, it is fine to keep the bug private throughout its lifetime. |
| Line 50: | Line 56: |
| 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 58: |
| * 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 60: |
| Our DebuggingProcedures can tell you what extra information should be included for particular classes of bugs. | = Confirming = |
| Line 59: | Line 62: |
| 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, '''ANY''' of which is sufficient: |
| Line 80: | Line 70: |
| 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 73: |
| * 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 77: |
| == 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. = 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 = |
| Line 92: | Line 90: |
A list of bugs that need to be forwarded [https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&orderby=-importance&field.status%3Alist=Unconfirmed&field.status%3Alist=Needs+Info&field.status%3Alist=Confirmed&field.status%3Alist=In+Progress&field.status%3Alist=Fix+Committed&assignee_option=any&field.assignee=&field.owner=&field.component-empty-marker=1&field.status_upstream=pending_bugwatch&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.tag=&field.has_no_package.used=&search=Search upstream]. |
|
| Line 106: | Line 106: |
| * Link to the bug inside Malone, in the form: https://launchpad.net/bugs/###### | * Link to the bug inside Malone, in the form: `https://launchpad.net/bugs/######` |
| Line 119: | Line 119: |
| == Rejecting == | If the remote bug tracker is not [https://bugs.launchpad.net/bugs/bugtrackers/ already registered] with Malone, you should [https://bugs.launchpad.net/bugs/bugtrackers/+newbugtracker add it]. (Or if you cannot, [https://launchpad.net/malone/+filebug file a bug on malone].) |
| Line 121: | Line 121: |
| 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. | == 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, but not assign a bug watch * 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, the program was designed to behave a certain way, or the report is actually a feature or support 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 125: | Line 137: |
| There is no need to reject bugs that are already marked as duplicates of other bugs. Doing so creates bug mail noise, and makes it more difficult to un-duplicate the bug later if that turns out to be necessary. = 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. |
|
| Line 126: | Line 150: |
| Go back to '''[:HelpingWithBugs]'''.[[BR]][[BR]] |
ContentsBRTableOfContents |
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. Without any risk of death.
Ubuntu receives an incredibly large number of bug reports every day through our BugTrackingSystem. Each one of these needs to be read, assessed, and sorted before being fixed. This is where we could use your assistance with HelpingWithBugs.
Untriaged bugs
[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 has been triaged it will no longer show up in this search.
You can use the Advanced search in the BugTrackingSystem to find untriaged 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 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.
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.
Join the https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs MailingList [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.
When 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. If no one else has commented yet, then this bug could be yours!
Include(Bugs/MarkingDuplicate)
Apport crash reports
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.
In Feisty and early Gutsy, those bugs were public, so that everyone can 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 [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.
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 [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.
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 ("Visibility/security" in the top left pink box). 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.
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:
- 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
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.
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.
Forwarding a bug is a bit of work, but it's well worth it. Here's what you do:
- 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.
When you report a new bug, please include the following information:
Link to the bug inside Malone, in the form: https://launchpad.net/bugs/######
- Credit the initial reporter.
- Provide a complete description of the problem.
Linking a bug report is much easier:
- 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".
If the remote bug tracker is not [https://bugs.launchpad.net/bugs/bugtrackers/ already registered] with Malone, you should [https://bugs.launchpad.net/bugs/bugtrackers/+newbugtracker add it]. (Or if you cannot, [https://launchpad.net/malone/+filebug file a bug on malone].)
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, but not assign a bug watch
- 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, the program was designed to behave a certain way, or the report is actually a feature or support 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.
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 duplicates of other bugs. Doing so creates bug mail noise, and makes it more difficult to un-duplicate the bug later if that turns out to be necessary.
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.
Go back to [:HelpingWithBugs].BRBR CategoryBugSquad
Bugs/Triage (last edited 2017-02-14 00:06:22 by teward)