Introduction

Bugs relating to KDE typically fall into 3 categories:

1. User interface bugs - require a detailed description of the issue, steps to reproduce and screen captures where appropriate.
2. Incorrect Functionality - require a detailed description of the issue, steps to reproduce and screen captures where appropriate.
3. Crasher bugs - Log files from the crash incident are required to track down these.

Some possible problems with bug reports include:

1. Hardware specific bugs - The developers may not have access to the hardware that triggers this bug. Certain log files and command outputs can help. For KDE, this can be relevant e.g. in configuration dialogs.
2. Package selection - [:DebuggingKDE#head-700ed3979b895dbb8fa78c9516ed89c536bea345:Help to find the right package]

How to file

See [:Kubuntu/Bugs/Reporting:Reporting Bugs].

Choosing the right package

Include(Kubuntu/Bugs/ChoosingTheRightPackage)

Upstream

bugs.kde.org

Most parts of KDE use [http://bugs.kde.org KDE's Bug Tracking System]. If you think a bug is in KDE and not Kubuntu specific, please search for it at [http://bugs.kde.org KDE's Bug Tracking System] and file one there if need be. Link the upstream bug in the launchpad bug by clicking "Also Effects Upstream." A bug with an upstream report should usually be Confirmed (you often shouldn't file it upstream if it's not).

Projects using Launchpad

Katapult

Bug tags

Bug tags specific to the package or area should be included here for reporters so they can tag their bug report.

Note: When adding new tags, the Bugs/Tags wiki page should then be modified to include these tags.

Debugging procedure

For information on how to debug KDE applications, see:

• http://techbase.kde.org/index.php?title=Development/Tutorials/Debugging

• http://techbase.kde.org/index.php?title=Development/Tutorials/Debugging/How_to_create_useful_crash_reports

• http://techbase.kde.org/index.php?title=Development/FAQs/Debugging_FAQ

How to Triage

TODO: This information is dated. It needs to be updated for the new bug statuses in launchpad, among other things.

What does triaging bugs mean?

• Responding to new bugs as they are filed.
• Reproducing and confirming bug repots.
• Asking the reporter to provide missing information.
• Searching for duplicates in the bug tracking system.

• Sending bugs to their upstream authors, when applicable. For KDE this is http://bugs.kde.org

• Cross-referencing bugs from other distributions.
• Classifying bugs by package.
• Prioritizing bugs.
• Expiring old bugs.

Suggestions and rules

• Read the wiki pages:

  • UbuntuBugDay

  • HelpingWithBugs

  • ["Bugs/HowToTriage"]

  • BugSquad

  • ["Bugs/Responses"]

• Be polite!

• Unconfirmed ("New") bugs are a priority. An unconfirmed bug isn't of much use to a developer or to the reporter. It's a waste of developers' time to try to figure out if things are even real bugs, so that's our job. Do your best to reproduce bugs so that you can confirm them.
• Bug reports often lack essential information required to fix them or to find out if they are already fixed. This can range from basic information such as what release they are using or even what program the bug is in to slightly more complex things like stack traces for crashes. Ask the reporter for any missing information. Be clear and polite. When you ask questions, mark the bug status as "Needs Info" until all the required information is provided. If you can reproduce the bug, provide the information yourself and mark "Confirmed."

• Duplicate bug reports are common. When you are looking at a new bug, open up another window and do an advanced search for similar bugs, including ALL bugs -- closed and open. If you are certain a bug report is a duplicate, mark it that way and comment on the bug to inform the reporter. Usual responses for this can be found [https://wiki.ubuntu.com/Bugs/Responses#head-c9465ec0d0c312bab06eac061dbdc6d2071204d1 here]. Other than this, avoid commenting on bugs marked as duplicates -- comment on the root bug.

• Many bugs have already been fixed. For older bugs that you cannot reproduce, ask if the reporter is sill having the problem. If the problem was fixed with an update, you can close the bug ("Fix Released").

• Bugs that are marked as "Needs Info" for over 3 months with a clear request for information but without a response that you can't reproduce aren't particularly useful. They should be "Rejected." When closing a bug for this reason, be polite and inform the reporter why you are closing it, and tell them that they can reopen the bug if they still have the problem and can provide the needed information. Some responses for this can be found [https://wiki.ubuntu.com/Bugs/Responses#head-aa72b6a41481a1304f6cc8dc0b076db1c288ff10 here].

• If you think a bug is in KDE and not Kubuntu specific, please search for it at [http://bugs.kde.org KDE's Bug Tracking System] and file one there if need be. Link the upstream bug in the launchpad bug by clicking "Also Effects Upstream." A bug with an upstream report should usually be Confirmed (you often shouldn't file it upstream if it's not). These bugs probably won't get fixed for Feisty, but can do a lot to improve the next version of KDE.

• Pick an application that you use a lot, and concentrate on it. This helps narrow down the list of bugs you are looking at and makes the work much more manageable. It also helps to be knowledgeable in the program(s) you are doing bug work for.
• If you have some rare configuration, look at bugs relating to it. For example, if you have a dual monitor setup, try to confirm some xinerama related bugs. This is particularly helpful since many other people who come across those bugs have no way of doing anything with them.
• Keep all this in mind when filing your own bugs.
• Don't confirm your own bugs.
• Don't duplicate efforts. If there is already someone working on a bug and asking the right questions, move on to another one. There are plenty to go around.

• There's a [http://people.ubuntu-in.org/~carthik/bugstats/ nice bug statistics page] that shows open and unconfirmed bugs over various periods of time. If you make a visible dent in those graphs, feel proud: you've done an excellent job helping Kubuntu. Be sure to get your well deserved Hugs!

• Keep in mind that while closing bugs is important, the key is that the bugs are FIXED.

• DO get on #ubuntu-bugs if you need help, to discuss bugs, and to watch for incoming bugs. #ubuntu+1 can also be useful to discuss Hardy problems with other users. Don't use #kubuntu for this.

Stock Reply

TODO: A stock reply to be used for initial bug reports basically asking for the stuff in "How to file". The Bugs/Responses page should include this reply. [:../Bugs/Responses:Responses to use when triaging]

How to Forward

If you think a bug is in KDE and not Kubuntu specific, please search for it at [http://bugs.kde.org KDE's Bug Tracking System] and file one there if need be. Link the upstream bug in the launchpad bug by clicking "Also Effects Upstream." A bug with an upstream report should usually be Confirmed (you often shouldn't file it upstream if it's not). These bugs probably won't get fixed for Hardy, but can do a lot to improve the next version of KDE.

Known bugs

TODO: Description of known bug reports that may receive duplicates and how to recognise them. This information should be obtained by looking for bugs tagged as 'metabug'.

Open

Closed

Other useful bug lists

Here are the major Kubuntu Desktop packages and their bugs: https://launchpad.net/~kubuntu-team/+packagebugs

A [https://bugs.launchpad.net/ubuntu/?field.searchtext=kde+%7C+kubuntu&orderby=-importance&search=Search&field.status%3Alist=Unconfirmed&assignee_option=any&field.assignee=&field.owner=&field.component-empty-marker=1&field.status_upstream=&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= vague list] of all the unconfirmed bugs in Kubuntu.

Non-bugs

TODO: How to recognise common issues arising from hardware failures, common feature requests and other invalid bugs for this category. Advice how triage them and stock responses.

FAQ

Why can't I change the importance of bugs?

• You need to be a member of the ubuntu-qa team on launchpad to change the importance of bugs. This is mostly so people are responsible and don't raise the importance of their own bugs. See UbuntuBugControl for more information.

Also see

• DebuggingProcedures

CategoryBugSquad CategoryDebugging