Bug Tips
Zurück
Weiter

Bug Tips

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 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.

The correct package for bugs in the Linux kernel is linux, regardless of which particular package is in use (there are many packages which contain Linux kernels).

Confirming problems

If a bug is marked as Unconfirmed, it is helpful for you to try to reproduce the problem and record the results in Malone. 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 that should be recorded in a comment.

Forwarding bugs upstream

You can 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 change is too hard to be fixed by yourself or anyone else on the team

If you do this, be sure to include all the necessary information, such as

  • how to reproduce the bug

  • which version is used (which version of dependent libraries, if the bug indicates problems there)

  • who reported it

  • where the whole conversation can be found

Make sure to also create a bug watch in Malone for this bug.

How to Deal with Feature Requests

If you feel that the bug reported is a 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 introduce the reporter gently to the Support Tracker we have. Be sure to mention http://launchpad.net/support.

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 discussion forum. If this change has already been discussed and rejected, explain the reasons to the user and direct him or her to the relevant discussion for further suggestions/comments.

Duplikate finden

Doppelt berichtete Bugs zu finden ist ein sehr wertvoller Beitrag zu der Bug Gemeinde. Benutzer wissen manchmal nicht, wie sie herausfinden können, ob ihr Bug schon eingetragen wurde, manchmal kümmert Sie das auch gar nicht... Einfach nur "ICH AUCH" Nachrichten abzusondern und solche Aussagen anzuhäufen ist für den Prozess, den Bug zu beseitigen nicht gerade hilfreich.

There are quite a few measures you can take to assist with this aspect. One is to search for bugs filed for the same component. Also try to rephrase your search, and concentrate on actions and words that describe the items involved to reproduce the bug.

Beispiele:

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 quickly in the beginning. After some time, you will recognize the usual suspects and will be able to identify them more easily.

Anmerkung

Wenn Sie einen Bug finden, der einen schreklich unpassenden Titel haben, bitte schreiben Sie ihn um, sodass andere Leute den Bug schneller finden können.

Reminder of the Code of Conduct

Note that the Code of Conduct applies to conversations in bug reports too. If you observe people being disrespectful, please direct them to the Ubuntu Code of Conduct.

Managing Status

As a reporter you usually don't have to take care of statuses. As a bug triager or developer it's an important tool to categorize bugs and have a good overview of the state of packages and software.

Hier ist eine kurze Liste und Erklärung der verschiedenen Statusbezeichnungen:

  • Unconfirmed: (unbestätigt) Jeder Bug hat am Anfang diesen Status, Bugs die als unbestätigt markiert sind haben manchmal zu wenig Informationen, sind noch nicht bereit oder nich nicht bestätigt. Die meisten von ihnen wurden noch nicht von anderen Benutzern angesehen.

  • Needs Info: If you have to ask the reporter questions, please set this bug to "Needs Info". A regular task for Needs Info bugs is to ask back. If there are no answers after a reasonable period, close them saying "If you have more information on this bug, please reopen."

  • Rejected: (abgelehnt) Bugs die als "Rejected" markiert sind wurden abgelehnt. Prüfen Sie einen Bug bitte mehrfach, befor sie ihn als abgelehnt markieren.

  • Confirmed: (bestätigt) Bugs müssen durch eine dritte Person bestätigt werden, bitte bestätigen Sie nicht ihre eigenen Bugs.

  • In Progress: (in Bearbeitung) Wenn sie anfangen an der Lösung eines Bugs zu arbeiten, setzen Sie den Status bitte auf "In Progress", sodass andere Leute wissen, dass sich jemand um das Problem kümmert.

  • Fix Committed: For upstream projects this means the fix is in CVS/SVN/bzr or committed somewhere. For package maintainers it means that the changes are pending and to be uploaded soon (it is what PENDINGUPLOAD is in Bugzilla)

  • Fix Released: (behoben und veröffentlicht) Für ein Upstream Projekt heißt das, dass ein Tarball angekündigt wurde und öffentlich erhältlich ist. Für Paketinstandhalter heißt das, dass eine Version, in dem der Bug behoben ist hochgeladen wurde. Bitte zögern Sie nicht und fügen ein changelog als ein Kommentar hinzu, sodass die Leute weiß welche Änderungen ihre Bugs betreffen.

Managing Severity

Ubuntu uses the following guidelines for assigning severity:

  • Wishlist: a request to add a new feature to one of the programs in Ubuntu. Use this for bugs which aren't really bugs but ideas for new features which do not yet exist.

  • Minor: bugs that affect functionality, but to a lesser extent than most bugs

  • Normal: a functionality bug of the standard variety. Most bugs are of "Normal" severity.

  • Major: a bug that has a severe impact on a small portion of Ubuntu users (estimated) or has a moderate impact on a large portion of Ubuntu users (estimated)

  • Critical: a bug which has a severe impact on a large portion of Ubuntu users

Target Milestone

Don't change this field unless specifically instructed to 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.

Zurück
Weiter
Zum Anfang