CommonTasks
|
Size: 2307
Comment:
|
Size: 8276
Comment: Fixed some of the formatting. Still not sure if this page is needed since it basically copies HowToTriage, but it might be wanted as a summarization.
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Forwarding bugs upstream == | <<Include(BugSquad/Header)>> |
| Line 3: | Line 3: |
| You can forward bugs upstream, if * you made sure, that the bug doesn't occur because of Ubuntu related changes * the change too hard to fix for yourself and anyone else in the team |
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents>>|| |
| Line 7: | Line 5: |
| If you do this, be sure to * include all the necessary information, like * how to reproduce * which version is used (which version of dependend libraries, if the bug indicates problems there) * who reported it * where the whole conversation is to be found * create a bug watch in Malone for this |
== Common Tasks of Bugsquad == |
| Line 15: | Line 7: |
| == How to Deal with Feature Requests == If you feel that the bug reported is a feature request disguised as bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention ["SpecTemplate"] and http://launchpad.net/specs == How to deal with Support Requests == If you feel that the bug reported is a support request disguised as bug report, please introduce the reporter gently to the Support Trackker we have. Be sure to mention http://launchpad.net/support |
Here we have a list of common tasks performed by BugSquad members. Feel free to jump in with whatever looks interesting. For a more detailed explanation of what is involved in triaging, please see [[https://wiki.ubuntu.com/Bugs/HowToTriage|How To Triage]]. If you have any more specific questions don't hesitate to join #ubuntu-bugs on [[IRC]] (irc.freenode.net) and give a shout. |
| Line 24: | Line 10: |
| == Finding Duplicates == | === Finding the proper source package === |
| Line 26: | Line 12: |
| Finding Duplicates of bugs is a very valuable contribution in the Bug community. Users sometimes don't know, how to check if the same bug was already filed, and sometimes don't care. To weed out simple '''ME TOO''' messages and aggregate information in one place is crucial in the process of fixing a bug. | Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in {{{Ubuntu}}}. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to {{{Ubuntu}}}. Some hints on finding the right package can be found in [[Bugs/FindRightPackage]]. |
| Line 28: | Line 14: |
| There are quite some measures you can take to help out with this specifically. | The correct package for bugs in the Linux kernel is dependent upon the release of Ubuntu being used. |
| Line 30: | Line 16: |
| Look up bugs for the same component. Try to rephrase your search concentrate on ''actions'' an ''words that describe'' the items involved to reproduce this crash. | * For Dapper (6.06) the correct package is {{{linux-source-2.6.15}}} * For Edgy (6.10) the correct package is {{{linux-source-2.6.17}}} * For Feisty (7.04) the correct package is {{{linux-source-2.6.20}}} * For Gutsy (7.10) the correct package is {{{linux-source-2.6.22}}} * For Hardy (8.04) - Lucid (10.04) the correct package is {{{linux}}} |
| Line 32: | Line 22: |
| Examples: | === Confirming problems === |
| Line 34: | Line 24: |
| * Easy ones: * [http://bugzilla.ubuntu.com/show_bug.cgi?id=18808 DAAP support] is a duplicate of * [http://bugzilla.ubuntu.com/show_bug.cgi?id=18733 please enable daap] * Hard ones: * [http://bugzilla.ubuntu.com/show_bug.cgi?id=17858 plug:spdif on emu10k1 gone after breezy upgrade] is a duplicate of * [http://bugzilla.ubuntu.com/show_bug.cgi?id=15585 Muted sound after dist-upgrade from Hoary to Breezy] If you can't find it in the list of open bugs, you could try to find it in the list of closed ones. Don't feel discouraged, if you don't find duplicates fast in the beginning, after some time you will know the usual suspects. |
If a bug is marked as New, it is helpful for you to try to reproduce the problem, and record the results in Launchpad. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment. When confirming the bug be sure to indicate which version of the package you used. One way to get the package version is via {{{dpkg -l $pkgname}}} where {{{$pkgname}}} is the name of the package you are testing. '''Note:''' Do not confirm your own bugs - confirmation is required from someone other than the original reporter. === Forwarding bugs upstream === You should forward bugs to the authors of the software (upstream), if: * You made sure that the bug doesn't occur because of Ubuntu related changes, * The bug report is complete. To learn how to do this, please consult [[https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding%20upstream|HowToTriage/ForwardingUpstream]] === How to deal with Feature Requests === If you feel that the bug reported is a non-trivial feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, [[SpecTemplate]] and http://launchpad.net/specs === How to deal with Support Requests === If you feel that the bug reported is a support request disguised as a bug report, please gently introduce the reporter to the Support Tracker located at http://answers.launchpad.net/ubuntu/ . === How to deal with suggestions for changing defaults === If you feel that the bug reported is a suggestion for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments. === Duplicates === 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: * 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(Bugs/Responses, , from="^== A duplicate ==$", to="^==")>> * Then click the "Mark as Duplicate" link at the top left of the bug report page, and enter the number of the primary bug. By default, searches in Launchpad and mentioned 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 an "Advanced Search". There is also a standardized tag for bugs likely to have lots of duplicates -- [[https://launchpad.net/ubuntu/+bugs?field.tag=metabug|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 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). === Reminder of the Code of Conduct === Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please direct them to http://www.ubuntu.com/community/conduct === Setting Status === <<Include(Bugs/Status, , ,from="Header.*$", to="^----")>> === Setting Importance === <<Include(Bugs/Importance, , ,from="Header.*$", to="^----")>> === Milestone === Don't change this field unless specifically instructed by a developer. In particular, do NOT use this field to record the release of Ubuntu in which the bug was observed: that is not its purpose! It is used by the release team when there is a reason to address the bug in a specific milestone release. === Old Bugs === In many cases bugs reported in earlier versions are still open in our bug tracking system. They may have been fixed upstream without it being noted in Launchpad or the design may have changed so that the issue is no longer relevant. If the bug does not represent a security issue or is otherwise critical, it is very unlikely that the fix will be back-ported to older versions of Ubuntu. When it is fixed in the development branch it is therefore most appropriate to mark it 'Fix Released'. This helps clear the bug tracking system for old cruft. ---- Back to '''[[HelpingWithBugs]]'''.<<BR>><<BR>> [[CategoryBugSquad]] |
Common Tasks of Bugsquad
Here we have a list of common tasks performed by BugSquad members. Feel free to jump in with whatever looks interesting. For a more detailed explanation of what is involved in triaging, please see How To Triage. If you have any more specific questions don't hesitate to join #ubuntu-bugs on IRC (irc.freenode.net) and give a shout.
Finding the proper source package
Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in Ubuntu. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to Ubuntu. Some hints on finding the right package can be found in Bugs/FindRightPackage.
The correct package for bugs in the Linux kernel is dependent upon the release of Ubuntu being used.
For Dapper (6.06) the correct package is linux-source-2.6.15
For Edgy (6.10) the correct package is linux-source-2.6.17
For Feisty (7.04) the correct package is linux-source-2.6.20
For Gutsy (7.10) the correct package is linux-source-2.6.22
For Hardy (8.04) - Lucid (10.04) the correct package is linux
Confirming problems
If a bug is marked as New, it is helpful for you to try to reproduce the problem, and record the results in Launchpad. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment. When confirming the bug be sure to indicate which version of the package you used. One way to get the package version is via dpkg -l $pkgname where $pkgname is the name of the package you are testing.
Note: Do not confirm your own bugs - confirmation is required from someone other than the original reporter.
Forwarding bugs upstream
You should forward bugs to the authors of the software (upstream), if:
- You made sure that the bug doesn't occur because of Ubuntu related changes,
- The bug report is complete.
To learn how to do this, please consult HowToTriage/ForwardingUpstream
How to deal with Feature Requests
If you feel that the bug reported is a non-trivial feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, SpecTemplate and http://launchpad.net/specs
How to deal with Support Requests
If you feel that the bug reported is a support request disguised as a bug report, please gently introduce the reporter to the Support Tracker located at http://answers.launchpad.net/ubuntu/ .
How to deal with suggestions for changing defaults
If you feel that the bug reported is a suggestion for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments.
Duplicates
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:
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 ==$"!
These standard responses along with other amazing scripts are also available as a Firefox extension in a PPA at:
This page is part of the Bug Squad’s KnowledgeBase - pages with information about how to triage bugs. https://launchpad.net/~gm-dev-launchpad/+archive/ppa
When you update one of these responses, you should also update the response used by the Firefox extension. These responses can be found in the bazaar branch lp:ubuntu-bugcontrol-tools in the file gm-xml-files/bugsquad-replies.xml. To check out a branch, use
bzr branch lp:ubuntu-bugcontrol-tools
Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see this email message), and they can be used when replying to a bug report if merged.
Contents
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.
By default, searches in Launchpad and mentioned 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 an "Advanced Search". There is also a standardized tag for bugs 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 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).
Reminder of the Code of Conduct
Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please direct them to http://www.ubuntu.com/community/conduct
Setting Status
Include: Nothing found for "Header.*$"!
Include: Nothing found for "^----"!
Setting Importance
Ubuntu uses the following guidelines for assigning importance. The importance of the bug signifies the priority that it should be given by people fixing bugs.
In order to set the Importance field of a bug in Launchpad, you need to be a member of UbuntuBugControl either through direct membership or because of your membership in another team. The importance of the bug should be set as soon as possible.
The importance of a bug report can be modified by clicking on the current Status or Importance, in the yellow line and under the "Affects" column header, which will reveal a sub menu. You can then choose a new importance in the drop down box.
Here are the meanings of the different importance values:
Undecided: The default for new bugs. Also means that there is insufficient information to determine importance.
Wishlist: Missing functionality.
- These aren't always bugs, but can be ideas for new features which do not yet exist.
- These can also be requests to have software packaged for Ubuntu.
If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications.
- These can be bugs that affect an experimental extension or non-essential feature of a given package/project.
Bugs that would only be fixed on a best-effort or outside-contribution basis might also be considered wishlist.
Low: Bugs which affect functionality, but to a lesser extent than most bugs, examples are:
Bugs that have easy work-arounds
- Bugs that affect unusual end-user configurations or uncommon hardware
- Bugs that affect a non-essential aspect and limited scope of the application
- Bugs that have a moderate impact on a non-core application
- Cosmetic/usability issues that does not limit the functionality of a non-core application
- Non-ideal default configurations
Medium: Most bugs are of medium importance, examples are:
- A bug that has a moderate impact on a core application.
- A bug that has a severe impact on a non-core application.
- A bug which impacts accessibility of a non-core application.
- A usability issue that does not limit the functionality of a core application.
- A problem with a non-essential hardware component (removable network card, camera, webcam, music player, sound card, power management feature, printer, etc.)
High: A bug which fulfills any of the following criteria:
- Has a severe impact on a small portion of Ubuntu users (estimated)
- Makes a default Ubuntu installation generally unusable for some users
- For example, if the system fails to boot, or X fails to start, on a certain make and model of computer
- A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse)
- Has a moderate impact on a large portion of Ubuntu users (estimated)
- Prevents the application or any dependencies from functioning correctly at all
- Renders essential features or functionality of the application or dependencies broken or ineffective
- Impacts accessibility of a core application
Critical: A bug that has a severe impact on a large portion of Ubuntu users
- Causes data corruption
- Crashes the entire operating system
- For example, if the system fails to boot, or X fails to start, on various makes and models of computer
- Renders the system temporarily or permanently unusable
- Severely affects applications beyond the package responsible for the root cause
|
Milestone
Don't change this field unless specifically instructed by a developer. In particular, do NOT use this field to record the release of Ubuntu in which the bug was observed: that is not its purpose! It is used by the release team when there is a reason to address the bug in a specific milestone release.
Old Bugs
In many cases bugs reported in earlier versions are still open in our bug tracking system. They may have been fixed upstream without it being noted in Launchpad or the design may have changed so that the issue is no longer relevant. If the bug does not represent a security issue or is otherwise critical, it is very unlikely that the fix will be back-ported to older versions of Ubuntu. When it is fixed in the development branch it is therefore most appropriate to mark it 'Fix Released'. This helps clear the bug tracking system for old cruft.
Back to HelpingWithBugs.
CategoryBugSquad
Bugs/CommonTasks (last edited 2011-06-15 18:35:14 by c-98-246-63-231)