CommonTasks
|
Size: 2307
Comment:
|
Size: 4519
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was renamed from Bugs/CommonTasksDraft == Overview == [[TableOfContents]] == 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 == 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. Do not confirm your own bugs - confirmation is required from someone other than the original reporter. |
|
| Line 3: | Line 25: |
| 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 |
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. |
| Line 7: | Line 29: |
| 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 |
To learn how to do this, please consult [https://wiki.ubuntu.com/Bugs/HowToTriage#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7 The Forwarding section in the How to Triage Page]. |
| Line 15: | Line 31: |
| == How to Deal with Feature Requests == | == How to deal with Feature Requests == |
| Line 17: | Line 33: |
| 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 | 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 |
| Line 21: | Line 38: |
| 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 | 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/ . |
| Line 24: | Line 41: |
| == Finding Duplicates == | == How to deal with suggestions for changing defaults == |
| Line 26: | Line 43: |
| 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. | 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. |
| Line 28: | Line 45: |
| There are quite some measures you can take to help out with this specifically. | [[Include(Bugs/MarkingDuplicate)]] |
| Line 30: | Line 47: |
| 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. | == Reminder of the Code of Conduct == |
| Line 32: | Line 49: |
| Examples: | 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 |
| Line 34: | Line 52: |
| * 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. |
== Setting Status == [[Include(Bugs/Status, , ,from="^Bug statuses", to="^----" )]] == Setting Importance == [[Include(Bugs/Importance, , 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] |
Overview
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
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. 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#head-ab0eb9d7731fa877b5fc866eedc4c312dab50ee7 The Forwarding section in the How to Triage Page].
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.
Include(Bugs/MarkingDuplicate)
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="^Bug statuses", to="^----" )
Setting Importance
Include(Bugs/Importance, , 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"].BRBR [:CategoryBugSquad]
Bugs/CommonTasks (last edited 2011-06-15 18:35:14 by c-98-246-63-231)