UbuntuWiki:Bugs/HowToTriage

出自Ubuntu中文

文章出处: 

https://wiki.ubuntu.com/Bugs/HowToTriage

点击翻译: 

English

请不要直接编辑翻译本页，本页将定期与来源同步。

<<Include(Bugs/BugsHeader)>> 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 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

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. 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 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 ("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. <<Include(Bugs/Improving)>>

[编辑] 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

<<Include(Bugs/Upstream)>>

[编辑] 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 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.

[编辑] 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. In the meantime, you can leave this standard 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 Feature Request to improve Ubuntu, you are invited to post your idea in Ubuntu Brainstorm at [WWW] https://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!

[编辑] 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 have any of the following teams subscribed:

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

[编辑] Needs Packaging Bugs

You may find a bug with a subject like: [needs-packaging] <package>. These bugs are used to track software requested for inclusion in Ubuntu. For these bugs, please:

  • 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.
  • if not in Debian or Ubuntu, then set the status to Confirmed, the importance to Wishlist (if possible), and add the tag needs-packaging if absent.
  • additionally one could check the Work-Needing and Prospective Packages page at Debian. In the event you find a bug for the same software requested in the Debian bug tracker please add an upstream bug watch for it.
  • see the Example Request for desired information.

/!\ Note: not all package names are intuitive! Also use package descriptions to help guide you. 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.

[编辑] 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: [1] You can see you subscribed bugs at [2], or the bugs you've commented on at [3]. 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.<
><
>

取自"http://wiki.ubuntu.org.cn/UbuntuWiki:Bugs/HowToTriage"