Difference between revisions of "Guidelines and HOWTOs/Bug triaging"

Jump to: navigation, search
(Better ordering of topics as a low-hanging fruit improvement. Some cleanups.)
(Cleanups, simplification, tautophony, grammar etc.)
Line 15: Line 15:
  
 
=General Considerations=
 
=General Considerations=
* '''Be polite''': when you need to request information or feedback be clear and polite, and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations, or even about contributors). Try to be concise and polite, respecting the other's position while describing your own.
+
* '''Be polite''': when you need to request information or feedback be clear and polite and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations or even about contributors). Try to be concise and polite, respecting the other's position while describing your own.
  
* Don't try to do too many things at the same time; you will end up with a headache!
+
* Don't try to do too many things at the same time - you will end up with a headache!
  
 
* If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick Introduction to Bugzilla]
 
* If you are not familiar with the Bugzilla (KDE bug tracker system) interface, you may find this guide useful: [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla Quick Introduction to Bugzilla]
  
* You may want to properly setup your bugzilla account as mentioned at [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla#Configure_your_account_.28Important.29 Configure your account]
+
* You may want to properly setup your Bugzilla account as mentioned at [http://techbase.kde.org/Contribute/Bugsquad/Quick_Introduction_to_Bugzilla#Configure_your_account_.28Important.29 Configure your account]
  
 
=Trying to reproduce the bugs=
 
=Trying to reproduce the bugs=
Line 31: Line 31:
 
You may want to use this reference text to setup your testing environment: [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]
 
You may want to use this reference text to setup your testing environment: [http://forum.kde.org/viewtopic.php?f=9&t=84475 Preparing a testing environment]
  
{{Note|It is also important to have an updated KDE SC installation to test bugs.}}
+
{{Note|It is also important to have up-to-date KDE components installed to test bugs.}}
  
 
==How to test bug reproducibility==
 
==How to test bug reproducibility==
  
# Read the *complete* bug report (including all the attached information). Note that some bits of information may look unrelated; but they could be useful (or not)
+
# Read the '''complete''' bug report (including all the attached information). Note that some bits of information may look unrelated, but they might be useful
# Use the information in the first comment (the original bug description) to try to reproduce the bug in the application.
+
# Usually you will try to reproduce the bug based on the description, but sometimes the comments provide updated reproduction steps, so it make sense to scan them before you start
# If you can reproduce the bug, then go to the next step
+
# If you can reproduce the bug, go to the next step
#* If you can't reproduce the bug, use the next comment in the report (which may add new information) to try to reproduce.
+
#* If you can't reproduce with any scenario mentioned in the comments, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one). Hopefully, you will find a combination that reproduces the bug reliably. Note down the newly found steps to reproduce so you can Include them in your comment
#* If you can't reproduce with all the comments in a separate way, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one) and similar combinations. You often have to use your imagination a bit (hopefully we still have time). Hopefully, you may find a combination that may reproduce the bug all (or most of) the times. Write down the "recipe" (steps to reproduce it), you need to include that data into the report later.
 
 
# Now that we have a result, we need to add our information/conclusions to the bug report
 
# Now that we have a result, we need to add our information/conclusions to the bug report
  
{{Tip|When trying to reproduce a bug, and if there are more than one piece of information, at first glance, try to identify a *common situation*. (some data or context that is present in all (or most of) the cases). This kind of data may be the key to find out how to reproduce.}}
+
{{Tip|When faced with a report containing scattered pieces of information, try to identify a *common situation* (some data or context that is present in all (or most of) the cases). This kind of data may be the key to finding out the reproduction steps.}}
  
 
==Adding new information (and requesting feedback)==
 
==Adding new information (and requesting feedback)==
  
* In any case, add your KDE SC version and system information. (other kind of configuration data may be useful to: "did you tested it on a clean environment or in your existing configuration ?"  "do you have library X installed and updated ?" "is your system 32 or 64 bits ?")
+
* In any case, add the versions of your KDE components and your system information. Other kinds of configuration data might also be useful: "did you test it on a clean environment or in your existing configuration?"  "do you have library X installed and updated ?" "is your system 32- or 64-bit ?"
  
 
'''If you could reproduce the bug''':
 
'''If you could reproduce the bug''':
 
   
 
   
* If you had to combine several steps to make your own "recipe" to reproduce, write it down. This kind of information should be useful for the developers.
+
* If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers.
 
   
 
   
* If you had to use custom input data (text, or a file); you may want to attach it to the bug report (of course, if it is not attached already)
+
* If you had to use custom input data (text, or a file), you may want to attach it to the bug report
  
A template of a comment for this situation could be:
+
A template for a comment in this situation could be:
  
  I can reproduce the bug here using KDE SC x.y.z, Qt a.b.c on Distribution,
+
  I can reproduce the bug here using KDE Frameworks x.y.z, Qt a.b.c on Distribution,
  Kernel d.e.f on XX bits.
+
  XX-bit Kernel d.e.f.
 +
 
  In order to reproduce I have to perform the following actions:
 
  In order to reproduce I have to perform the following actions:
  1- Action 1
+
  2- Action 2
+
  1. Action 1
  3- Action 3
+
  2. Action 2
  4- Bug Appears
+
  3. Action 3
  Note that you need to have the X configuration set to Y, and use the Z library
+
  4. Bug Appears
  - Can anyone else confirm this ?
+
Thanks
+
  Note that you need to have the X configuration set to Y, and use the Z library.
 +
  Can anyone else confirm this?
  
 
'''If you could not reproduce the bug''':
 
'''If you could not reproduce the bug''':
 
   
 
   
* Write down which kind of steps you performed to try to get the bug.
+
* Write down the steps you performed to try to see the bug
  
* You may want to ask to all the reporters if your step had missing something, or if they notice any other strange (or not-default) situation or configuration which may be related.
+
* You may want to ask, if your steps missed something, or if anyone notices any other strange (or non-default) situation or configuration which may be related
  
* Also, if the report is a bit old (more than two major KDE SC releases old), you could try to ask the reporters if you can reproduce the bug in the latest stable KDE SC release or trunk (development version). The bug may be fixed already (but no one wrote it down into the bug report). If a comment indicates that the bug is resolved, close the bug as WORKSFORME, and refer to the comment in which the reporter indicated being unable to reproduce.
+
* Also, if the report is several months old, you could try to ask the reporter if they can reproduce the bug in the latest stable KDE components releases or trunk (development version). The bug may be fixed already (but no one mentioned it in the bug report). If a comment indicates that the bug is resolved, close the bug as WORKSFORME, and refer to the comment in which the reporter indicated being unable to reproduce.
  
A template of comment for this situation could be:
+
A template for a comment in this situation could be:
  
  I couldn't reproduce the bug here using KDE SC x.y.z, Qt a.b.c
+
  I couldn't reproduce the bug here using KDE Frameworks x.y.z, Qt a.b.c
  on Distribution, Kernel d.e.f on XX bits.
+
  on Distribution, XX-bit Kernel d.e.f.
 +
 
  I tried performing these actions:
 
  I tried performing these actions:
  1- Action 1
+
  2- Action 2
+
  1. Action 1
 +
  2. Action 2
 +
 
  or
 
  or
  1a- Action 1a
+
  2a- Action 2a
+
  1a. Action 1a
 +
  2a Action 2a
 +
 
  However, the bug didn't appear/the application didn't crash
 
  However, the bug didn't appear/the application didn't crash
  - Are you all using library X and this kind of configuration ?
+
   
  - Can you still reproduce this bug with an updated KDE SC version ?
+
Are you all using library X and this configuration?
Thanks
+
  Can you still reproduce this bug with updated KDE Frameworks?
  
 
Hopefully you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as WORKSFORME (or FIXED).
 
Hopefully you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as WORKSFORME (or FIXED).
  
 
=Get permission to work on the bug tracker=
 
=Get permission to work on the bug tracker=
Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work; or it may end up messing things up (and consuming the developers' or other triager's time) the tracker requires special permissions to perform changes in bug reports.
+
Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work or it may mess things up (and consume the developers' or other triager's time) the tracker requires special permissions to perform changes in the fields of bug reports.
  
 
If you want to be able to change the field data in bug reports, you need to prove that you know what you are doing. Some examples of this proof are prior helpful comments and triaging action on KDE bugs, prior experience triaging bugs in a professional setting. To request access, ask in the '''#kde-bugs''' [[Internet Relay Chat | IRC channel]].
 
If you want to be able to change the field data in bug reports, you need to prove that you know what you are doing. Some examples of this proof are prior helpful comments and triaging action on KDE bugs, prior experience triaging bugs in a professional setting. To request access, ask in the '''#kde-bugs''' [[Internet Relay Chat | IRC channel]].
Line 109: Line 115:
 
In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).
 
In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).
  
You can focus on crash, normal or wish reports individually (recommended) or all of them together.
+
You can focus on crash, normal or wishlist reports individually (recommended) or all of them together.
  
 
'''Good:'''
 
'''Good:'''
Line 122: Line 128:
 
* You may not pay too much attention to every report, as you are triaging different kinds of reports
 
* You may not pay too much attention to every report, as you are triaging different kinds of reports
 
* You need a lot of attention to handle the different reports (at the ~same~ time)
 
* You need a lot of attention to handle the different reports (at the ~same~ time)
 
This technique could be used ''every week'' (or every day)
 
  
 
===Bugzilla Links===
 
===Bugzilla Links===
Line 133: Line 137:
 
==Check bug reports of a single product over a period of time==
 
==Check bug reports of a single product over a period of time==
  
Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beggining (like 2000)). You can also choose which kind of reports you want to handle.
+
Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beginning (like 2000)).
  
This technique is useful to audit old bugs or perform a deep clean (in case that the bugs weren't triaged on a daily basis previously).
+
This technique is useful to audit old bugs or perform a deep clean (in case the bugs weren't triaged on a daily basis previously).
  
 
'''Good:'''
 
'''Good:'''
* You focus only on one product / topic, so you don't need to pay too much attention (pay attention anyways!)
+
* You focus only on one product / topic, so you don't need to pay too much attention
  
 
'''Not so Good:'''
 
'''Not so Good:'''
* The reports of the other application may rot if they aren't checked
+
* The reports of the other applications may rot if they aren't checked
 
* You may not get feedback if the report is too old or the reporter is not accessible anymore
 
* You may not get feedback if the report is too old or the reporter is not accessible anymore
  
 
You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).
 
You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).
 
This technique could be used ''two times a month''.
 
  
 
===Bugzilla Links===
 
===Bugzilla Links===
Line 163: Line 165:
 
There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful piece of information for the developers to check.
 
There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful piece of information for the developers to check.
  
{{Note|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask to the developers or related contributors}}
+
{{Note|if at any point you don't really know how to continue, because you don't understand the issue properly, always ask the developers or related contributors}}
  
As KDE has so many users, we get a lot of reports about bugs which are already reported (the so named "duplicates"). Before putting any effort in the current report we should check for the main report.
+
As KDE has so many users, we get a lot of reports about bugs which are already reported (duplicates). Before putting any effort in the current report we should check for an existing report.
  
 
==Identifying duplicates==
 
==Identifying duplicates==
  
There are a lot of ways of identifying duplicate reports depending of the kind of bug.
+
There are a lot of ways of identifying duplicate reports depending on the kind of bug.
  
 
===General===
 
===General===
  
* Search for duplicates should be done initially against the same product of the bug report you are triaging: 
If you don't find any related issue, you may need to search in a different product.
+
* A search for duplicates should be done initially against the product of the bug report you are triaging. 
If you don't find any related issues, you may need to search in a different product.
 
 
{{Tip|You can search on different products at the same time}}
+
{{Tip|You can search in different products at the same time}}
  
{{Note|Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be being tracked at a library product (example, a bug in Plasma Desktop may be a bug in kdelibs, and therefore being tracked in the "kdelibs" product)}}
+
{{Note|Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be tracked in a library product (example, a bug in Plasma Desktop may be a bug in kdelibs and therefore tracked in the "kdelibs" product)}}
  
 
[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies List of related KDE technologies]
 
[http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies List of related KDE technologies]
  
* You may want to filter out the results by date: you can select a date range since some years (or months ago) to "Now" (today)
+
* You may want to filter out the results by date: you can select a starting date from some years (or months) ago
  
 
===For "normal" (non-crash) reports===
 
===For "normal" (non-crash) reports===
  
# Pick some "keywords" from the current report. This keywords need to explain the inner concept of the bug that was reported (they must represent it).
+
# Pick some "keywords" from the current report. These keywords need to explain the what the bug is about
# Perform a full search over the same product (read general note), initially on the "general" component.
 Initially, put the keywords in the title, and perform the search (this will only look for the keywords in the title)
+
# Perform a full search over the same product, initially in the "general" component.
 Put the keywords in the summary field, and perform the search
# If your search has results on it, check them all, reading the whole description and trying to identify the situation.
+
# If your search has results in it, check them all, reading the whole description and trying to identify the situation
 
# If you don't get any results, you need to go back and:

 
# If you don't get any results, you need to go back and:

#* Change your keywords (tip: select thesaurus, or similar/related concepts); or
+
#* Change your keywords (tip: select thesaurus, or similar/related concepts) or
#* Use the keywords in the "Comments" field (so the search will look up in the bug description and comments too)
+
#* Use the keywords in the "Comments" field (so the search will look up in the bug description and comments)
  
 
{{Note|When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"}}
 
{{Note|When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"}}
  
{{Note|It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person (but we have time)}}
+
{{Note|It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person}}
  
 
===For "crash" reports===
 
===For "crash" reports===
Line 201: Line 203:
 
# Check for reports with duplicate backtraces: 
 (Read the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#C.2B.2B_Backtraces_.28identifying_crashes_duplicates.29 Backtraces section] below)
 
# Check for reports with duplicate backtraces: 
 (Read the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#C.2B.2B_Backtraces_.28identifying_crashes_duplicates.29 Backtraces section] below)
  
Perform a full search over the same product (read general note), initially on the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")
+
Perform a full search over the same product, initially in the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")
  
 
===Processing search results===
 
===Processing search results===
  
* If you don't find any similar report then we should assume the new bug reports is "unique" (and valid). See next section

+
* If you don't find any similar reports then we should assume the new bug report is unique.

 +
 
 +
* If you find a similar bug report we have two choices:
 +
** If you are completely sure it is the same issue, you have to mark the report as duplicate. 

The bug report you initially picked is going to be marked as duplicate of the original report. If the duplicate has additional information, you may want to add it to the original. Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase
 +
** If you aren't completely sure, you need someone else to double-check your work. You may want to add a comment in the current report. Then, you should ask in the #kde-bugs IRC channel for someone to look at your comment.
  
* If you find a similar bug report we have too choices:
 
** If you are completely sure it is the same issue, you have to mark the report as duplicate. 

The bug report you initially picked (name it "copy") is going to be marked as duplicate of the original report (name it "main"). If "copy" has additional information that "main" doesn't have, you may want to add it. (Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase)

 
** If you aren't completely sure: you need someone else to double check your work. You may want to add a comment in the current report. Then, you should ask in #kde-bugs IRC channel for someone to look at your comment.
 
 
Comment template:
 
Comment template:
 +
 
  This bug looks related to bug XXXXXX
 
  This bug looks related to bug XXXXXX
 
(XXXXXX being the bug ID of "master")
 
(XXXXXX being the bug ID of "master")
  
{{Note|You may found related reports that are already marked as duplicate of a third report. Always try to use this third report as the "main" one (resolve the duplicates chain). However, in some cases, the "main" reports refers to a root issue, and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.}}
+
{{Note|You may find related reports that are already marked as duplicate of a third report. Always try to use this third report as the main one (resolve the duplicates chain). However, in some cases, the main report refers to a root issue and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.}}
  
 
==Identifying duplicates (crashes) : C++ Backtraces==
 
==Identifying duplicates (crashes) : C++ Backtraces==
Line 220: Line 224:
 
===Definition===
 
===Definition===
  
A backtrace is a piece of information that describes what was the application doing when it encountered the error and had to close itself. It is a “function stack” leading to the “crashing point”.
+
A backtrace is a piece of information that describes what the application was doing when it encountered an error and had to close itself. It is a “function stack” leading to the “crashing point”.
  
 
In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.
 
In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.
  
The backtrace is read from top to bottom. The first line shows ''where'' the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issues). The other lines show the “way to the first function”.
+
The backtrace is read from top to bottom. The first line shows ''where'' the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issue). The other lines show the "way to the first function".
  
 
===Example===
 
===Example===
Line 259: Line 263:
 
  /source/code/file.cpp:linenumber
 
  /source/code/file.cpp:linenumber
  
* #NumberInTheStack: is the order number in the function stack. The lesser, the nearer to the crash point. The smaller number may not be zero
+
* #NumberInTheStack: is the order number in the function stack. The lesser the number, the nearer it is to the crash point. The smaller number may not be zero
* MemoryAddress: we don't put attention to this one.. Ignore
+
* MemoryAddress: we don't pay attention to this one.. Ignore
* Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could be also a class name if "Class" is an embedded one.
+
* Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could also be a class name if "Class" is an embedded one.
 
* Class: C++ class name of the function
 
* Class: C++ class name of the function
 
* FunctionMember: C++ function name
 
* FunctionMember: C++ function name
* argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example "this=0x91ec5f8"

other argument use the same form "parameterName=parameterValue"
+
* argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example: "this=0x91ec5f8"

 - other arguments use the same form "parameterName=parameterValue"
* (..): arguments supplied to the function. This information may not be available if *debug information* is not present


+
* (..): arguments supplied to the function. This information may not be available if '''debug information''' is not available
* path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function, and the line number. The path is the one found at '''build time'''. This information may not be useful if '''debug information''' is not available (in that case, the name of the library or application binary may be included. Example: ''/home/kde-devel/kde/lib/libsopranoclient.so.1'')
+
* path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function and the line number. The path is the one found at '''build time'''. This information may not be useful if '''debug information''' is not available (in that case, the name of the library or application binary may be included. Example: ''/home/kde-devel/kde/lib/libsopranoclient.so.1'')
  
 
'''Example''':
 
'''Example''':
Line 282: Line 286:
 
===Identifying the first (useful) backtrace functions===
 
===Identifying the first (useful) backtrace functions===
  
The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi)
+
The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi).
  
If the application only had one thread, then it is at the top of the unique thread; otherwise you may need to look at all the thread (the KCrash mark may not be always in the Thread number 1)
+
If the application only had one thread, then it is at the top of the unique thread. Otherwise you may need to look at all the threads (the KCrash mark may not always be in the Thread number 1).
  
Once that you located the "crashing thread start", pickup the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below)
+
Once you located the "crashing thread start", pick up the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below).
  
This pairs will be used as "keywords" for the duplicate search
+
These pairs will be used as "keywords" for the duplicate search.
  
{{Note|This is only a general rule. There are some special cases when the first three function at the top may be the same but the crash may be different (specially on complex application/libraries as Konqueror)}}
+
{{Note|This is only a general rule. There are some special cases when the first three functions at the top may be the same but the crash may be different (especially in complex application/libraries such as Konqueror)}}
  
If the first backtrace functions aren't available (they are not there, or there are "??") then we can't proceed without [[#Check_the_report_quality_.28and_ask_for_missing_information.29|asking for more information]] (a more complete backtrace).
+
If the first backtrace functions are not available (they are not there, or there are "??") then we cannot proceed without [[#Check_the_report_quality_.28and_ask_for_missing_information.29|asking for more information]] (a more complete backtrace).
  
 
===Avoiding useless function calls===
 
===Avoiding useless function calls===
  
Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). This kind of functions should not be used for search as they are not representative of the crash itself and it may return lots of results.
+
Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). These kinds of functions should not be used for searching as they are not representative of the crash itself and the search may return lots of results.
  
 
'''Classes and functions to ignore in a backtrace''':
 
'''Classes and functions to ignore in a backtrace''':
 
* Kernel/GLibC functions (<tt>__kernel_vsyscall</tt>, <tt>raise</tt>, <tt>abort</tt>)
 
* Kernel/GLibC functions (<tt>__kernel_vsyscall</tt>, <tt>raise</tt>, <tt>abort</tt>)
 
* Functions from core/base libraries (libraries with filenames like <tt>libpthread.so.0</tt>, <tt>libc.so</tt>, <tt>libstdc++.so</tt>, <tt>libglib-2.0.so</tt>; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
 
* Functions from core/base libraries (libraries with filenames like <tt>libpthread.so.0</tt>, <tt>libc.so</tt>, <tt>libstdc++.so</tt>, <tt>libglib-2.0.so</tt>; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
* Qt containers classes (<tt>QMap</tt>, <tt>QList</tt>, <tt>QLinkedList</tt>, <tt>QVector</tt>, <tt>QStack</tt>, <tt>QQueue</tt>, <tt>QSet</tt>, <tt>QMap</tt>, <tt>QMultiMap</tt>, <tt>QHash</tt>, <tt>QMultiHash</tt>)
+
* Qt container classes (<tt>QMap</tt>, <tt>QList</tt>, <tt>QLinkedList</tt>, <tt>QVector</tt>, <tt>QStack</tt>, <tt>QQueue</tt>, <tt>QSet</tt>, <tt>QMap</tt>, <tt>QMultiMap</tt>, <tt>QHash</tt>, <tt>QMultiHash</tt>)
 
* Qt deep core classes (<tt>QApplication</tt>, <tt>QCoreApplication</tt>, <tt>QBasicAtomicInt</tt>, <tt>QBasicAtomicPointer</tt>, <tt>QAtomicInt</tt>, <tt>QAtomicPointer</tt>, <tt>QMetaObject</tt>, <tt>QPointer</tt>, <tt>QWeakPointer</tt>, <tt>QSharedPointer</tt>, <tt>QScopedPointer</tt>, <tt>QMetaCallEvent</tt>)
 
* Qt deep core classes (<tt>QApplication</tt>, <tt>QCoreApplication</tt>, <tt>QBasicAtomicInt</tt>, <tt>QBasicAtomicPointer</tt>, <tt>QAtomicInt</tt>, <tt>QAtomicPointer</tt>, <tt>QMetaObject</tt>, <tt>QPointer</tt>, <tt>QWeakPointer</tt>, <tt>QSharedPointer</tt>, <tt>QScopedPointer</tt>, <tt>QMetaCallEvent</tt>)
 
* Qt misc functions (<tt>qt_message_output</tt>, <tt>qt_message</tt>, <tt>qGetPtrHelper</tt>, functions starting with <tt>qt_meta_</tt>)
 
* Qt misc functions (<tt>qt_message_output</tt>, <tt>qt_message</tt>, <tt>qGetPtrHelper</tt>, functions starting with <tt>qt_meta_</tt>)
  
===Special cases (Advanced)===  
+
===Special cases (advanced)===  
  
There are special crashes related to the X11 graphics server. To identify this crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.
+
There are special crashes related to the X11 graphics server. To identify these crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.
  
The important things to identify those crashes is recognizing the functions *below* the XIOError call (this is, which functions caused the X11 error).
+
The important thing in identifying these crashes is recognizing the functions '''below''' the XIOError call (which functions caused the X11 error).
  
In most of this crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).
+
In most of these crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).
  
 
==Bugs caused by external issues (UPSTREAM/DOWNSTREAM)==
 
==Bugs caused by external issues (UPSTREAM/DOWNSTREAM)==
Line 321: Line 325:
 
* Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)
 
* Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)
  
Distributions can also bring some trouble, specially with packaging.
+
Distributions can also bring some trouble, especially with packaging.
  
 
Some problems that may cause bugs are:
 
Some problems that may cause bugs are:
Line 327: Line 331:
 
* missing plugins (broken packaging) causing crashes or missing features.
 
* missing plugins (broken packaging) causing crashes or missing features.
  
Also, distribution can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize these unofficial add-ons.
+
Also, distributions can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize these unofficial add-ons.
  
If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot; other people may identify if it is a KDE application or an external addition.
+
If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot. Other people may be able to recognize an external add-on.
  
 
{{Note|The '''UPSTREAM''' resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11).  
 
{{Note|The '''UPSTREAM''' resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11).  
Line 336: Line 340:
 
==Check the report quality (and ask for missing information)==
 
==Check the report quality (and ask for missing information)==
  
Now that you know that the bug report is unique, and that is not an external issue, you need to check all the needed information is there.
+
Now that you know that the bug report is unique and that it is not an external issue, you need to check that all the needed information is there.
  
* Check that report is English and that is easily understandable.


+
* Check that report is in English and that is easily understandable.
 
** If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
 
** If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
** 

If the explanation is not clear enough, and you think that the bug could be described in a image, you may want to ask for a screenshot [explanation of Bugzilla attachments]
+
** 

If the explanation is not clear enough and you think that the bug could be described in an image, you may want to ask for a screenshot
 
+
* If the bug is a graphical glitch or issue, you may want to request a screenshot
* If the bug is a graphical glitch or issue, you may want to request a screenshot [explanation of Bugzilla attachments]
+
* If the issue involves any other component (like the graphics card or drivers), you may need to ask for the versions and component names
* If the issue involves any other component (like the graphics card or drivers) you may need to ask for the versions and component's names
+
* If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug symbols package, reproduce the bug and generate a new backtrace. Template for this request:
* If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug package symbols, reproduce the bug and generate a new backtrace. Template for this request:
 
 
   
 
   
 
  If you can reproduce the crash at will (or you experience this regularly),
 
  If you can reproduce the crash at will (or you experience this regularly),
 
  can you install the "PACKAGENAME" package and post a complete backtrace here?
 
  can you install the "PACKAGENAME" package and post a complete backtrace here?
  (you can get more information at http://techbase.kde.org/User:DarioAndres
+
  (you can get more information at http://techbase.kde.org/User:DarioAndres/Basic_Guide_about_Crash_Reporting)
/Basic_Guide_about_Crash_Reporting ) Thanks
+
Thanks
  
The names of the missing packages depends of the application and the distribution (as package naming scheme changes..). Look at List of debug package names on several Distributions
+
The names of the missing packages depend on the application and the distribution (as package naming schemes change). Look at the list of debug package names in several Distributions at the end of this article.
  
 
'''Useful information which could be also missing''':
 
'''Useful information which could be also missing''':
 
* Application version
 
* Application version
* KDE Platform (and/or Software Compilation) version
+
* KDE Frameworks version
* If the bug is about a crash, request the version of the Qt library
+
* Qt library version
* If the reporter is using an development version, request the Git or SVN revision of the KDE platform and application
+
* If the reporter is using an development version, request the Git or SVN revision of the KDE Frameworks and application
  
{{Note|If you don't get feedback after a period of time, you can mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}
+
{{Note|Feel free to mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" after asking for further information (or resolution "BACKTRACE" if you are waiting for a complete backtrace)}}
  
==Setting Bugzilla fields (and re-assignation)==
+
==Setting Bugzilla fields (and reassignation)==
  
 
Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):
 
Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):
  
 
* '''Version''': if the report has an application version, you need to set the version in the Bugzilla field. Ideally the version field should reflect the latest version the bug is reproducible with, and of course the other information in the bug (backtrace, description) should also reflect that same version. In the process of triaging old bug reports the version field is a good indicator for a bug that needs newer information.  
 
* '''Version''': if the report has an application version, you need to set the version in the Bugzilla field. Ideally the version field should reflect the latest version the bug is reproducible with, and of course the other information in the bug (backtrace, description) should also reflect that same version. In the process of triaging old bug reports the version field is a good indicator for a bug that needs newer information.  
** If the version is missing in the list, please contact the software maintainer or the KDE bugzilla admins to add the version in the system.
+
** If the version is missing in the list, please contact the software maintainer or the KDE Bugzilla admins to add the version in the system.
* '''Priority''': we don't use this field in the KDE bug tracker. The priority is used by the developers to organize their work, it should stay at normal and only changed by the developers of the project.
+
* '''Priority''': we don't use this field in the KDE bug tracker. The priority is used by the developers to organize their work, it should stay at normal and only be changed by the developers of the project.
* '''Severity''': If you are not really sure if a report describes a real bug or a feature; or if you cannot diagnose the issue, you need to ask in the support channels or wait for other triagers or developers to check the report.
+
* '''Severity''': If you are not really sure if a report describes a real bug or a feature or if you cannot diagnose the issue, you need to ask in the support channels or wait for other triagers or developers to check the report.
 
** some hints about the various severity options:
 
** some hints about the various severity options:
 
*** Critical: The software causes you to lose data.
 
*** Critical: The software causes you to lose data.
Line 375: Line 378:
 
*** Crash: The software crashes or hangs.
 
*** Crash: The software crashes or hangs.
 
*** Normal: It's a bug that should be fixed.
 
*** Normal: It's a bug that should be fixed.
*** Minor: minor loss of function, and there is an easy workaround.
+
*** Minor: Minor loss of function, and there is an easy workaround.
 
*** Wishlist: Request for a new feature or enhancement.
 
*** Wishlist: Request for a new feature or enhancement.
* '''Platform''': this field is only important if the bug is related to one distribution or specific system. (most of the bug reports are common to most of the platforms). Same with the OS field
+
* '''Platform''': this field is only important if the bug is related to one distribution or a specific system (most of the bug reports are common to most of the platforms). Same with the OS field
  
 
===Renaming a report: Updating the summary===
 
===Renaming a report: Updating the summary===
  
Most of the times, the reporter user initially sets the bug report's title, and therefore, the summary doesn't really represent the bug itself. You may want to update the title to contain enough information to identify the issue properly.
+
Most of the time the reporter sets the bug report's summary and therefore it might not accurately represent the bug. You may want to update the summary to contain enough information to identify the issue properly.
  
A good title may contain:
+
A good summary may contain:
  
 
* A brief explanation of the root cause (if it was found)
 
* A brief explanation of the root cause (if it was found)
 
* Some of the symptoms people are experiencing
 
* Some of the symptoms people are experiencing
* Additional comments between round brackets/parentheses
+
* Additional comments in brackets/parentheses
  
{{Tip|Try to use complete and easily readable english sentences as summary}}
+
{{Tip|Try to use complete and easily readable English sentences as the summary}}
  
 
* If the bug is about a crash, you may add the first useful ClassName::FunctionName pairs that identify it. You can put them inside square brackets at the end of the title
 
* If the bug is about a crash, you may add the first useful ClassName::FunctionName pairs that identify it. You can put them inside square brackets at the end of the title
Line 413: Line 416:
 
===Reassigning bug reports===
 
===Reassigning bug reports===
  
Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know to which application/library did the bug belong to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)
+
Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know which application/library the bug belongs to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)
  
{{Warning|Only perform re-assignations if you are sure the bug is in the wrong product.}}
+
{{Warning|Only perform reassignations if you are sure the bug is in the wrong product.}}
  
 
{{Note|Remember to check the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies KDE related technologies list]}}
 
{{Note|Remember to check the [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#List_of_related_KDE_technologies KDE related technologies list]}}
  
 
# Select the correct Bugzilla product.
 
# Select the correct Bugzilla product.
# If you are sure the current assignee is the default of the current product, you need to click the checkbox to reset the assignee (so the assignee of the new(and correct) Bugzilla product will get notified)
+
# If you are sure the current assignee is the default for the current product, you need to click the checkbox to reset the assignee (so the assignee of the new Bugzilla product will get notified)
# Commit the changes
+
# Save the changes
# In the next page, select the correct Component and Version, and save the changes
+
# In the next page, select the correct Component and Version and save the changes
  
 
==Adding related people to the CC list==
 
==Adding related people to the CC list==
  
Sometimes, the reports describe general issues or are filed against common bugzilla products (like "kde" or "kdelibs"); or, on the other round, are filed against specific products (but the underling bug root cause is at some specific library, not directly related to the current bugzilla product assignee)
+
Sometimes the reports describe general issues or are filed against common Bugzilla products (like "kde" or "kdelibs"). Conversely, they might be filed against specific products, but the underling root cause is in some specific library, not directly related to the current Bugzilla product assignee.
  
In both cases, if we don't need/want to reassign the report (because we aren't really sure about it), we can add the assignee of the other related products, or other developers mail address, to the CC list of the bug report.  
+
In both cases, if we don't need/want to reassign the report, we can add the assignee of the other related products, or other developer's mail address, to the CC list of the bug report.  
That means, this person (or people following a mailing list) will get notified about this bug report, and they might look at it.
+
This person (or people following a mailing list) will then get notified about this bug report and they might look at it.
  
To know whom to add to the CC list you can:
+
To know who to add to the CC list you can:
* Look at the [https://bugs.kde.org/editproducts.cgi list of bugzilla products and components] and find the current default assignee (this requires special "editcomponents" permissions)
+
* Look at the [https://bugs.kde.org/editproducts.cgi list of Bugzilla products and components] and find the current default assignee (this requires special "editcomponents" permissions)
* Look at copyright of the source code related to the bug. (You can always access the code using [http://websvn.kde.org/trunk/KDE/ WebSVN])
+
* Look at the copyright of the source code related to the bug. You can always access the code using [https://websvn.kde.org/trunk/ WebSVN]
* Ask in the IRC support channels which person is related to an specific KDE area (#kde-devel)
+
* Ask in the IRC support channels, if anyone knows which person is related to a specific KDE area (#kde-devel)
  
 
Common situation '''examples''':
 
Common situation '''examples''':
  
* A report against "Dolphin" describes a Nepomuk-related error.  
+
* A report against "Dolphin" describes a Baloo-related error.  
** Add the Nepomuk default assignee to the CC list
+
** Add the Baloo default assignee to the CC list
  
 
* A report against "Plasma" describes an error which seems to be more general (at kdelibs level), but you are not really sure if you should reassign it.
 
* A report against "Plasma" describes an error which seems to be more general (at kdelibs level), but you are not really sure if you should reassign it.
 
** Do not reassign and add "kdelibs-bugs___at___kde___dot___org" to the CC list
 
** Do not reassign and add "kdelibs-bugs___at___kde___dot___org" to the CC list
  
* A report against the "kde" bugzilla product describes a Konqueror-related issue (and you aren't sure it is a Konqueror-only issue)
+
* A report against the "kde" Bugzilla product describes a Konqueror-related issue (and you are not sure it is a Konqueror-only issue)
 
** Do not reassign and add "konq-bugs___at___kde___dot___org" to the CC list
 
** Do not reassign and add "konq-bugs___at___kde___dot___org" to the CC list
  
* A report against the "kde" bugzilla product describes a Plasma issue
+
* A report against the "kde" Bugzilla product describes a Plasma issue
** Reassign the report to the "plasma" bugzilla product; or
+
** Reassign the report to the "plasma" Bugzilla product; or
 
** Add "plasma-bugs___at___kde___dot___org" to the CC list
 
** Add "plasma-bugs___at___kde___dot___org" to the CC list
  
Line 455: Line 458:
 
===One report per issue===
 
===One report per issue===
  
There is a policy in KDE bugtracker which establishes that different issues/bugs should not be mixed up in the same bug report, in order to keep the database clean and easy to read.
+
There is a policy in the KDE bug tracker which establishes that different issues should not be mixed up in the same report, in order to keep the database clean and easy to read.
  
If any user adds information which is unrelated to the current bug report, gently tell him/her to write it down on a *different/new report. (The new issue described may be already reported somewhere else. In that case, you need to write a reference to the that bug report ID)
+
If any user adds information which is unrelated to the current bug report, gently tell them to write it down in a different/new report. The new issue described may be already reported somewhere else. In that case, you need to include a reference to that bug report ID.
  
 
=Getting bug triaging support=
 
=Getting bug triaging support=
  
During your work you may need help on how to proceed, you can use this resources to get help:
+
During your work you may need help on how to proceed. You can use these resources to get help:
  
* The '''#kde-bugs channel''' on IRC (Freenode.net). You can ask to the whole channel.
+
* The '''#kde-bugs channel''' on IRC (Freenode.net). You can ask the whole channel.
 
* The BugSquad mailing list <bugsquad ##at## kde ##dot## org>
 
* The BugSquad mailing list <bugsquad ##at## kde ##dot## org>
  
=BugWeeks=
 
 
We are planing to host bug triaging events (where new "students" can learn the tricks) named "BugWeeks" on a regular basis to help cleaning up the KDE bug tracker database.
 
 
The BugWeeks initiative is based on the Klassroom initiative in the KDE Community Forums
 
 
You can find more information about this at:
 
* [http://forum.kde.org/viewtopic.php?f=4&t=84473 BugWeeks announcement]
 
* [http://forum.kde.org/viewforum.php?f=148 BugWeeks subsection on KDE Community Forums]
 
* [http://forum.kde.org/viewtopic.php?f=148&t=84713 BugWeek 0 - Plasma Desktop bugs] ([http://forum.kde.org/viewtopic.php?f=148&t=84888 Summary])
 
 
=FAQ=
 
 
=More Information=
 
=More Information=
  
Line 484: Line 475:
 
* Every KDE application use kdelibs [Bugzilla product: '''"kdelibs"''']
 
* Every KDE application use kdelibs [Bugzilla product: '''"kdelibs"''']
 
* Applications using the standard KDE file operations use KIO [Bugzilla product: '''"kio"'''] and probably KFile (for the UI part) [Bugzilla product: '''"kfile"''']
 
* Applications using the standard KDE file operations use KIO [Bugzilla product: '''"kio"'''] and probably KFile (for the UI part) [Bugzilla product: '''"kfile"''']
* Oxygen widget style (default) [Bugzilla product: '''"oxygen"''' component '''"style"'''] (I'm adding the component because "Oxygen" also refers to a Plasma and icon themes)
+
* Oxygen widget style (default) [Bugzilla product: '''"oxygen"''' component '''"style"'''] (component is included because "Oxygen" also refers to Plasma and icon themes)
 
* Multimedia usage: Phonon library [Bugzilla product: '''"Phonon"''']
 
* Multimedia usage: Phonon library [Bugzilla product: '''"Phonon"''']
 
* PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: '''"kdepim"''', '''"kdepimlibs"''', '''"Akonadi"''', '''"kresources"''']
 
* PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: '''"kdepim"''', '''"kdepimlibs"''', '''"Akonadi"''', '''"kresources"''']
Line 498: Line 489:
 
==Special products and cases==
 
==Special products and cases==
  
* "systemsettings" contain bug reports of the Shell application SystemSettings and kcmshell4, and reports of the configuration modules "kcm_*"
+
* "systemsettings" contain bug reports for the Shell application SystemSettings and kcmshell4 and reports for the configuration modules "kcm_*"
** Try to identificate if the report is about the shell applications (and set the component to "general", "treeview" or "kcmshell") or about some of the configuration modules (and set the component to "kcm_*name*")
+
** Try to find out, if the report is about the shell applications (and set the component to "general", "treeview" or "kcmshell") or about some of the configuration modules (and set the component to "kcm_*name*")
  
 
* Konqueror can use different engines, like KHTML or WebKit
 
* Konqueror can use different engines, like KHTML or WebKit
 
** If the report is about a webkit-only issue, reassign to product "kdelibs", component "kdewebkit"
 
** If the report is about a webkit-only issue, reassign to product "kdelibs", component "kdewebkit"
  
{{Tip|When updating the bugzilla product or component, do not forget to reset to the default assignee}}
+
{{Tip|When updating the Bugzilla product or component, do not forget to reset to the default assignee}}
  
 
==Useful Links==
 
==Useful Links==
Line 560: Line 551:
 
|}
 
|}
  
For a detailed list of distributions naming scheme examples you can look at [http://techbase.kde.org/index.php?title=User:DarioAndres/CreateUsefulReports#How_to_obtain_debug_package_for_several_distributions How to obtain debug packages for every distribution].
+
For a detailed list of distribution naming scheme examples you can look at [http://techbase.kde.org/index.php?title=User:DarioAndres/CreateUsefulReports#How_to_obtain_debug_package_for_several_distributions How to obtain debug packages for every distribution].
  
 
==Glossary==
 
==Glossary==
  
* Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet, or to a set of steps.
+
* Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet or a set of steps.

Revision as of 22:22, 6 February 2018

Help Konqi catch some bugs!

KDE bug triagers verify that Bugzilla tickets describe real bugs, are accurate and reproducible, and that the reporter has given enough information. The goal is to save developers from doing this work, which helps them fix bugs more quickly and do more work on their software

You do not need any programming knowledge to be a bug triager, but experience has shown that members of this team often learn a lot in the course of dealing with bug reports, and many move on to developing the software itself. If you are just starting to learn programming, it's a great way to gain familiarity with the components and give practical support to the KDE community.

Getting started

The sheer number of open bugs can be overwhelming at the start. Here are some hints on getting started more smoothly:

  • Look at a single product at a time. For large applications (like Konqueror), you may want to further limit your search to a particular component.
  • Don't try to find duplicates early on. Finding duplicates is hard until you have become familiar with the bugs in a component. Start out with verifying UNCONFIRMED bugs as described above. That's valuable work, and a great way to familiarize yourself with the bug database.
  • Avoid very old bugs with many comments, and also bugs with many votes. This may seem counter-intuitive, but in most cases these bugs are hard, have gotten a lot of attention, and are probably on a developer's TODO list already. If it is from an older version of KDE, and there are no recent comments, verify them, make a notation, and move on.
  • Don't be afraid to ask the reporter for more info. It's something you can even do without Bugzilla permissions. And reporters will generally prefer being asked one question too many, instead of their report never being dealt with. Just remember to be polite. Ask yourself how you would feel if you got the message you are thinking about sending to a user.
  • Look at the incoming Bugzilla bugs. Or find the oldest bugs for your favorite software application.
  • Look through the rest of our documentation for more information!


General Considerations

  • Be polite: when you need to request information or feedback be clear and polite and you will get more information in less time. 
Often Bugzilla is a place which involves discussions (about implementations or even about contributors). Try to be concise and polite, respecting the other's position while describing your own.
  • Don't try to do too many things at the same time - you will end up with a headache!

Trying to reproduce the bugs

An important step of bug triaging is trying to reproduce the bugs. This means that you use the information provided by the reporter and try to make the bug manifest in your own system.

Warning.png
Warning
Testing bug reports may modify/alter your own desktop configuration; also, to try to reproduce some bugs you may need a clean pristine (or sightly modified) environment. We recommend you to perform tests on a separate KDE installation or a clean user. There is also a way to start KDE applications with a clean configuration, even under your current configuration (setting the KDEDIR environment variable at run-time to an empty directory).


You may want to use this reference text to setup your testing environment: Preparing a testing environment

Note-box-icon.png
Note
It is also important to have up-to-date KDE components installed to test bugs.


How to test bug reproducibility

  1. Read the complete bug report (including all the attached information). Note that some bits of information may look unrelated, but they might be useful
  2. Usually you will try to reproduce the bug based on the description, but sometimes the comments provide updated reproduction steps, so it make sense to scan them before you start
  3. If you can reproduce the bug, go to the next step
    • If you can't reproduce with any scenario mentioned in the comments, you may want to try combined situations (a bit of the description of the original bug, plus a bit of the second one). Hopefully, you will find a combination that reproduces the bug reliably. Note down the newly found steps to reproduce so you can Include them in your comment
  4. Now that we have a result, we need to add our information/conclusions to the bug report
Ktip.png
 
Tip
When faced with a report containing scattered pieces of information, try to identify a *common situation* (some data or context that is present in all (or most of) the cases). This kind of data may be the key to finding out the reproduction steps.


Adding new information (and requesting feedback)

  • In any case, add the versions of your KDE components and your system information. Other kinds of configuration data might also be useful: "did you test it on a clean environment or in your existing configuration?" "do you have library X installed and updated ?" "is your system 32- or 64-bit ?"

If you could reproduce the bug:

  • If you had to combine several steps to make your own "recipe" to reproduce, write them down. This kind of information is useful for the developers.
  • If you had to use custom input data (text, or a file), you may want to attach it to the bug report

A template for a comment in this situation could be:

I can reproduce the bug here using KDE Frameworks x.y.z, Qt a.b.c on Distribution,
XX-bit Kernel d.e.f.

In order to reproduce I have to perform the following actions:

1. Action 1
2. Action 2
3. Action 3
4. Bug Appears

Note that you need to have the X configuration set to Y, and use the Z library.
Can anyone else confirm this?

If you could not reproduce the bug:

  • Write down the steps you performed to try to see the bug
  • You may want to ask, if your steps missed something, or if anyone notices any other strange (or non-default) situation or configuration which may be related
  • Also, if the report is several months old, you could try to ask the reporter if they can reproduce the bug in the latest stable KDE components releases or trunk (development version). The bug may be fixed already (but no one mentioned it in the bug report). If a comment indicates that the bug is resolved, close the bug as WORKSFORME, and refer to the comment in which the reporter indicated being unable to reproduce.

A template for a comment in this situation could be:

I couldn't reproduce the bug here using KDE Frameworks x.y.z, Qt a.b.c
on Distribution, XX-bit Kernel d.e.f.

I tried performing these actions:

1. Action 1
2. Action 2

or

1a. Action 1a
2a Action 2a

However, the bug didn't appear/the application didn't crash

Are you all using library X and this configuration?
Can you still reproduce this bug with updated KDE Frameworks?

Hopefully you will get feedback from the reporters and you could gather more information to try to reproduce the bug or close the report as WORKSFORME (or FIXED).

Get permission to work on the bug tracker

Manpower is always needed in a bug tracker, but as any action taken on it may be potentially destructive to other people's work or it may mess things up (and consume the developers' or other triager's time) the tracker requires special permissions to perform changes in the fields of bug reports.

If you want to be able to change the field data in bug reports, you need to prove that you know what you are doing. Some examples of this proof are prior helpful comments and triaging action on KDE bugs, prior experience triaging bugs in a professional setting. To request access, ask in the #kde-bugs IRC channel.

Note-box-icon.png
Note
every user is allowed to add comments in any bug report; this can mark the start of your bug triaging!


Getting Started: Find what to work on (Different Approaches)

You could use different techniques or approaches to triage the reports according to your current mood or the amount of work you want to do for example.

Ktip.png
 
Tip
The two following techniques are complementary.


Check all the bug reports of the day

In this technique you check all the bug reports (of all the products) which were filed today (or some days ago).

You can focus on crash, normal or wishlist reports individually (recommended) or all of them together.

Good:

  • You get a complete view of all the reports
  • You can easily recognize possible duplicates if the report titles are appropriate
  • You can choose any report
  • You can quickly clean the bugs that were filed recently (keeping them from rotting)
  • You can get quick feedback from the reporter

Not so Good:

  • You don't focus on one product
  • You may not pay too much attention to every report, as you are triaging different kinds of reports
  • You need a lot of attention to handle the different reports (at the ~same~ time)

Bugzilla Links

Check bug reports of a single product over a period of time

Choose a product (application or library). Then choose a period of time like 1 month or 1 or 2 years (or "from the beginning of the current year", or even from the very beginning (like 2000)).

This technique is useful to audit old bugs or perform a deep clean (in case the bugs weren't triaged on a daily basis previously).

Good:

  • You focus only on one product / topic, so you don't need to pay too much attention

Not so Good:

  • The reports of the other applications may rot if they aren't checked
  • You may not get feedback if the report is too old or the reporter is not accessible anymore

You can also filter out results (and be even more focused) if you select a custom component inside the product (a subsection of the application).

Bugzilla Links

Workflow of the bug triaging activity

Now that you have a list of bug reports, pick one and start working.

DarioAndres GuideToBugTriaging Workflow.png

Handling reports: What to do with a bug report

There are several things that must be checked and "fixed" to make an initial bug report an interesting and useful piece of information for the developers to check.

Note-box-icon.png
Note
if at any point you don't really know how to continue, because you don't understand the issue properly, always ask the developers or related contributors


As KDE has so many users, we get a lot of reports about bugs which are already reported (duplicates). Before putting any effort in the current report we should check for an existing report.

Identifying duplicates

There are a lot of ways of identifying duplicate reports depending on the kind of bug.

General

  • A search for duplicates should be done initially against the product of the bug report you are triaging. 
If you don't find any related issues, you may need to search in a different product.

Ktip.png
 
Tip
You can search in different products at the same time


Note-box-icon.png
Note
Due to the heavy usage of libraries in the KDE software, a bug reported for an application may be tracked in a library product (example, a bug in Plasma Desktop may be a bug in kdelibs and therefore tracked in the "kdelibs" product)


List of related KDE technologies

  • You may want to filter out the results by date: you can select a starting date from some years (or months) ago

For "normal" (non-crash) reports

  1. Pick some "keywords" from the current report. These keywords need to explain the what the bug is about
  2. Perform a full search over the same product, initially in the "general" component.
 Put the keywords in the summary field, and perform the search
  3. If your search has results in it, check them all, reading the whole description and trying to identify the situation
  4. If you don't get any results, you need to go back and:

    • Change your keywords (tip: select thesaurus, or similar/related concepts) or
    • Use the keywords in the "Comments" field (so the search will look up in the bug description and comments)
Note-box-icon.png
Note
When using more than one word in the "Comments" field you need to select the option "contains all of the words/strings"


Note-box-icon.png
Note
It is sometimes difficult to choose the proper ones, as the way of describing a scene varies from person to person


For "crash" reports

  1. Perform the same operation as with normal bug reports
  2. Check for reports with duplicate backtraces: 
 (Read the Backtraces section below)

Perform a full search over the same product, initially in the "general" component, putting the "ClassName::FunctionName" pairs that identify the crash in the Comments field of the form (if you put more than one pair, you need to select the option "contains all of the words/strings")

Processing search results

  • If you don't find any similar reports then we should assume the new bug report is unique.

  • If you find a similar bug report we have two choices:
    • If you are completely sure it is the same issue, you have to mark the report as duplicate. 

The bug report you initially picked is going to be marked as duplicate of the original report. If the duplicate has additional information, you may want to add it to the original. Note: some details may look unimportant to you, but they may be important for developers who know about the application workflow and code. Also, adding a big amount of minimal/incomplete information you may end up generating a big and complete testcase
    • If you aren't completely sure, you need someone else to double-check your work. You may want to add a comment in the current report. Then, you should ask in the #kde-bugs IRC channel for someone to look at your comment.

Comment template:

This bug looks related to bug XXXXXX

(XXXXXX being the bug ID of "master")

Note-box-icon.png
Note
You may find related reports that are already marked as duplicate of a third report. Always try to use this third report as the main one (resolve the duplicates chain). However, in some cases, the main report refers to a root issue and some of its duplicates may refer to sub-issues. In those cases try to check which one refers to the issue you are looking at.


Identifying duplicates (crashes) : C++ Backtraces

Definition

A backtrace is a piece of information that describes what the application was doing when it encountered an error and had to close itself. It is a “function stack” leading to the “crashing point”.

In KDE applications, the backtraces are generated by the Crash Handler Dialog (“DrKonqi”). They can also be generated by the general debugger “GDB”, but that involves more steps.

The backtrace is read from top to bottom. The first line shows where the crash occurred (because of an illegal instruction, invalid pointer, memory problem or other issue). The other lines show the "way to the first function".

Example

Application: Plasma Workspace (kdeinit4), signal: Bus error
[KCrash Handler]
#5  0x00007fb563bb8f02 in KPixmapCache::Private::mmapFile (this=0x92df60, 
filename=..., info=0x92dfb0, newsize=33656832) at /usr/src/debug/kdelibs-
4.4.1/kdeui/util/kpixmapcache.cpp:491
#6  0x00007fb563be3c34 in KPixmapCache::Private::mmapFiles (this=0x92df60) at 
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:419
#7  0x00007fb563be38e3 in KPixmapCache::Private::init (this=0x92df60) at 
/usr/src/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1061
#8  0x00007fb563be576d in KPixmapCache::discard (this=0x1203ca0) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1279
#9  0x00007fb563be5e48 in KPixmapCache::deleteCache (name=...) at /usr/src
/debug/kdelibs-4.4.1/kdeui/util/kpixmapcache.cpp:1255
#10 0x00007fb55afdc97d in Plasma::ThemePrivate::discardCache (this=0x7a7d30) 
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:224
#11 0x00007fb55afe009b in Plasma::ThemePrivate::setThemeName (this=0x7a7d30, 
tempThemeName=<value optimized out>, writeSettings=<value optimized out>)
at /usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:380
#12 0x00007fb55afe19fb in Plasma::Theme::settingsChanged (this=0x70af20) at 
/usr/src/debug/kdelibs-4.4.1/plasma/theme.cpp:341
#13 0x00007fb55afe2918 in Plasma::ThemePrivate::settingsFileChanged 
(this=0x7a7d30, file=<value optimized out>) at /usr/src/debug/kdelibs-
4.4.1/plasma/theme.cpp:335
...

Description of a backtrace line

#NumberInTheStack MemoryAddress in Namespace::Class:FunctionMember 
(argumentThis=pointerValue, argument1=value, argument2=value, ...) at path/to
/source/code/file.cpp:linenumber
  • #NumberInTheStack: is the order number in the function stack. The lesser the number, the nearer it is to the crash point. The smaller number may not be zero
  • MemoryAddress: we don't pay attention to this one.. Ignore
  • Namespace: C++ namespace of the function. It may not be available if there are no namespaces. This could also be a class name if "Class" is an embedded one.
  • Class: C++ class name of the function
  • FunctionMember: C++ function name
  • argumentThis=pointerValue : this first argument is often the memory address/pointer of the C++ object (example: "this=0x91ec5f8"

 - other arguments use the same form "parameterName=parameterValue"
  • (..): arguments supplied to the function. This information may not be available if debug information is not available
  • path/to/source/code/file.cpp:linenumber the path to the source code file that describes that function and the line number. The path is the one found at build time. This information may not be useful if debug information is not available (in that case, the name of the library or application binary may be included. Example: /home/kde-devel/kde/lib/libsopranoclient.so.1)

Example:

#13 0xb759d5d7 in Nepomuk::ResourceData::determineUri (this=0x91ec5f8) at 
/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp:671
  • The function is the number 13 in the stack
  • Function's namespace: "Nepomuk"
  • Function's class: "ResourceData"
  • Function's function: "determineUri"
  • The object "Nepomuk::ResourceData" which called to "determineUri" has the pointer "0x91ec5f8"
  • The function is described (where it was build) at "/home/kde-devel/kde/src/KDE/kdelibs/nepomuk/core/resourcedata.cpp". It leads to the next function in the stack at the line number 671

Identifying the first (useful) backtrace functions

The first thing you need to do is to locate where it crashed, identifying the "[KCrash Handler]" mark (only in backtraces fetched using DrKonqi).

If the application only had one thread, then it is at the top of the unique thread. Otherwise you may need to look at all the threads (the KCrash mark may not always be in the Thread number 1).

Once you located the "crashing thread start", pick up the first two or three "ClassName::Functions" pairs from top to bottom (some functions should be ignored, read below).

These pairs will be used as "keywords" for the duplicate search.

Note-box-icon.png
Note
This is only a general rule. There are some special cases when the first three functions at the top may be the same but the crash may be different (especially in complex application/libraries such as Konqueror)


If the first backtrace functions are not available (they are not there, or there are "??") then we cannot proceed without asking for more information (a more complete backtrace).

Avoiding useless function calls

Some functions or calls are common to a lot of applications using the same core libraries (like the Qt library, glib, glibc, or many others). These kinds of functions should not be used for searching as they are not representative of the crash itself and the search may return lots of results.

Classes and functions to ignore in a backtrace:

  • Kernel/GLibC functions (__kernel_vsyscall, raise, abort)
  • Functions from core/base libraries (libraries with filenames like libpthread.so.0, libc.so, libstdc++.so, libglib-2.0.so; or functions starting with "*__GI_"). You may also need to ignore calls to graphics drivers (like nvidia or libGL)
  • Qt container classes (QMap, QList, QLinkedList, QVector, QStack, QQueue, QSet, QMap, QMultiMap, QHash, QMultiHash)
  • Qt deep core classes (QApplication, QCoreApplication, QBasicAtomicInt, QBasicAtomicPointer, QAtomicInt, QAtomicPointer, QMetaObject, QPointer, QWeakPointer, QSharedPointer, QScopedPointer, QMetaCallEvent)
  • Qt misc functions (qt_message_output, qt_message, qGetPtrHelper, functions starting with qt_meta_)

Special cases (advanced)

There are special crashes related to the X11 graphics server. To identify these crashes you can search for the "XIOError" function name (often on Thread 1). The "[KCrash handler]" mark appears in a secondary thread.

The important thing in identifying these crashes is recognizing the functions below the XIOError call (which functions caused the X11 error).

In most of these crashes the functions below "[KCrash handler]" are not important (but they could still be useful to search for duplicates).

Bugs caused by external issues (UPSTREAM/DOWNSTREAM)

Check if the bug is caused by an external plugin/add-on or distribution issue

There are several bugs which may be caused by external add-ons. If you are sure this is the case, you should dismiss the report, telling the reporter to file a new bug in a different place.

  • Applications which use plugins may be easier to affect (like Plasma when using custom Plasmoids/widgets)

Distributions can also bring some trouble, especially with packaging.

Some problems that may cause bugs are:

  • different versions among KDE packages (kdelibs at one version, kdebase at a different one)
  • missing plugins (broken packaging) causing crashes or missing features.

Also, distributions can include their own add-ons (to bring their own branding or any other special function). If you know KDE software enough you may be able to recognize these unofficial add-ons.

If the reporter mentions an application or dialog you cannot identify, you could try requesting a screenshot. Other people may be able to recognize an external add-on.

Note-box-icon.png
Note
The UPSTREAM resolution refers to bugs caused by libraries/dependencies, upstream in the software stack (like Qt, glibc, X11). The DOWNSTREAM resolution refers to bug caused by the Distributions (broken packaging, ...) or by external plugins (unofficial Plasma widgets, other extensions, ...)


Check the report quality (and ask for missing information)

Now that you know that the bug report is unique and that it is not an external issue, you need to check that all the needed information is there.

  • Check that report is in English and that is easily understandable.

    • If it is not in English you may want to look for someone on the KDE group (IRC channels) that may translate it for you. Alternatively you can ask the reporter to use some online translation system (you won't get a clear explanation, but it is something).
    • 

If the explanation is not clear enough and you think that the bug could be described in an image, you may want to ask for a screenshot
  • If the bug is a graphical glitch or issue, you may want to request a screenshot
  • If the issue involves any other component (like the graphics card or drivers), you may need to ask for the versions and component names
  • If the bug report is about a crash and the backtrace information is not really complete (and you couldn't perform a duplicate search) you need to ask the user to install the missing debug symbols package, reproduce the bug and generate a new backtrace. Template for this request:
If you can reproduce the crash at will (or you experience this regularly),
can you install the "PACKAGENAME" package and post a complete backtrace here?
(you can get more information at http://techbase.kde.org/User:DarioAndres/Basic_Guide_about_Crash_Reporting)
Thanks

The names of the missing packages depend on the application and the distribution (as package naming schemes change). Look at the list of debug package names in several Distributions at the end of this article.

Useful information which could be also missing:

  • Application version
  • KDE Frameworks version
  • Qt library version
  • If the reporter is using an development version, request the Git or SVN revision of the KDE Frameworks and application
Note-box-icon.png
Note
Feel free to mark the report as "NEEDSINFO" with resolution "WAITINGFORINFO" after asking for further information (or resolution "BACKTRACE" if you are waiting for a complete backtrace)


Setting Bugzilla fields (and reassignation)

Often the bug reports aren't properly categorized, or they miss some information in the Bugzilla fields (which are useful for sorting and filtering):

  • Version: if the report has an application version, you need to set the version in the Bugzilla field. Ideally the version field should reflect the latest version the bug is reproducible with, and of course the other information in the bug (backtrace, description) should also reflect that same version. In the process of triaging old bug reports the version field is a good indicator for a bug that needs newer information.
    • If the version is missing in the list, please contact the software maintainer or the KDE Bugzilla admins to add the version in the system.
  • Priority: we don't use this field in the KDE bug tracker. The priority is used by the developers to organize their work, it should stay at normal and only be changed by the developers of the project.
  • Severity: If you are not really sure if a report describes a real bug or a feature or if you cannot diagnose the issue, you need to ask in the support channels or wait for other triagers or developers to check the report.
    • some hints about the various severity options:
      • Critical: The software causes you to lose data.
      • Grave: The software is basically unusable now.
      • Major: A major feature is broken.
      • Crash: The software crashes or hangs.
      • Normal: It's a bug that should be fixed.
      • Minor: Minor loss of function, and there is an easy workaround.
      • Wishlist: Request for a new feature or enhancement.
  • Platform: this field is only important if the bug is related to one distribution or a specific system (most of the bug reports are common to most of the platforms). Same with the OS field

Renaming a report: Updating the summary

Most of the time the reporter sets the bug report's summary and therefore it might not accurately represent the bug. You may want to update the summary to contain enough information to identify the issue properly.

A good summary may contain:

  • A brief explanation of the root cause (if it was found)
  • Some of the symptoms people are experiencing
  • Additional comments in brackets/parentheses
Ktip.png
 
Tip
Try to use complete and easily readable English sentences as the summary


  • If the bug is about a crash, you may add the first useful ClassName::FunctionName pairs that identify it. You can put them inside square brackets at the end of the title
  • If the report has additional information (like a testcase file, or an attached proposed patch) you may add those references as tags at the start of the summary (inside square brackets)

Examples:

[patch] Plasma clock draws garbage when hovering it if the Ctrl key is pressed
Dolphin hangs when trying to view the properties of a big file
[testcase file] Plasma crashes when adding a special file to the panel
[Class1::Function1, Class1::Function2, Class2::Function3]
Applications that use Plasma themes crash when compositing is switched on/off
due an error in KPixmapCache [KPixmapCache::Private::mmapFile,
KPixmapCache::Private::init, KPixmapCache::discard]
[testcase url] Konqueror shows a graphical artifact in webpage's form when
scrolling

Reassigning bug reports

Some of the reports are assigned to the wrong product. This may happen because the original reporter didn't know which application/library the bug belongs to. It may happen if the Crash Handler dialog reports a crash about an unsupported application (or one that is not mapped properly)

Warning.png
Warning
Only perform reassignations if you are sure the bug is in the wrong product.


Note-box-icon.png
Note
Remember to check the KDE related technologies list


  1. Select the correct Bugzilla product.
  2. If you are sure the current assignee is the default for the current product, you need to click the checkbox to reset the assignee (so the assignee of the new Bugzilla product will get notified)
  3. Save the changes
  4. In the next page, select the correct Component and Version and save the changes

Adding related people to the CC list

Sometimes the reports describe general issues or are filed against common Bugzilla products (like "kde" or "kdelibs"). Conversely, they might be filed against specific products, but the underling root cause is in some specific library, not directly related to the current Bugzilla product assignee.

In both cases, if we don't need/want to reassign the report, we can add the assignee of the other related products, or other developer's mail address, to the CC list of the bug report. This person (or people following a mailing list) will then get notified about this bug report and they might look at it.

To know who to add to the CC list you can:

  • Look at the list of Bugzilla products and components and find the current default assignee (this requires special "editcomponents" permissions)
  • Look at the copyright of the source code related to the bug. You can always access the code using WebSVN
  • Ask in the IRC support channels, if anyone knows which person is related to a specific KDE area (#kde-devel)

Common situation examples:

  • A report against "Dolphin" describes a Baloo-related error.
    • Add the Baloo default assignee to the CC list
  • A report against "Plasma" describes an error which seems to be more general (at kdelibs level), but you are not really sure if you should reassign it.
    • Do not reassign and add "kdelibs-bugs___at___kde___dot___org" to the CC list
  • A report against the "kde" Bugzilla product describes a Konqueror-related issue (and you are not sure it is a Konqueror-only issue)
    • Do not reassign and add "konq-bugs___at___kde___dot___org" to the CC list
  • A report against the "kde" Bugzilla product describes a Plasma issue
    • Reassign the report to the "plasma" Bugzilla product; or
    • Add "plasma-bugs___at___kde___dot___org" to the CC list

Other Situations and Cases

One report per issue

There is a policy in the KDE bug tracker which establishes that different issues should not be mixed up in the same report, in order to keep the database clean and easy to read.

If any user adds information which is unrelated to the current bug report, gently tell them to write it down in a different/new report. The new issue described may be already reported somewhere else. In that case, you need to include a reference to that bug report ID.

Getting bug triaging support

During your work you may need help on how to proceed. You can use these resources to get help:

  • The #kde-bugs channel on IRC (Freenode.net). You can ask the whole channel.
  • The BugSquad mailing list <bugsquad ##at## kde ##dot## org>

More Information

List of related KDE technologies

  • Every KDE application use kdelibs [Bugzilla product: "kdelibs"]
  • Applications using the standard KDE file operations use KIO [Bugzilla product: "kio"] and probably KFile (for the UI part) [Bugzilla product: "kfile"]
  • Oxygen widget style (default) [Bugzilla product: "oxygen" component "style"] (component is included because "Oxygen" also refers to Plasma and icon themes)
  • Multimedia usage: Phonon library [Bugzilla product: "Phonon"]
  • PIM related applications use kdepimlibs, Akonadi and kresources technologies [Bugzilla products: "kdepim", "kdepimlibs", "Akonadi", "kresources"]
  • Applications using KHTML [Bugzilla product: konqueror"]
  • Applications using OpenDesktop services uses Attica [Bugzilla product: "attica"]
  • Screen management related operations use the Kephal subsystem [Bugzilla product: "kephal"]
  • Games use libkdegames [Bugzilla product: "libkdegames"]
  • Scanning related applications probably use the KSane lib [Bugzilla product: "libksane"]
  • Multimedia applications reading audio tags use taglib [Bugzilla product: "taglib"]
  • Hardware related functions use Solid classes [Bugzilla product: "solid"]
  • Power Management functions use PowerDevil [Bugzilla product: "solid", component: "powerdevil-daemon"]

Special products and cases

  • "systemsettings" contain bug reports for the Shell application SystemSettings and kcmshell4 and reports for the configuration modules "kcm_*"
    • Try to find out, if the report is about the shell applications (and set the component to "general", "treeview" or "kcmshell") or about some of the configuration modules (and set the component to "kcm_*name*")
  • Konqueror can use different engines, like KHTML or WebKit
    • If the report is about a webkit-only issue, reassign to product "kdelibs", component "kdewebkit"
Ktip.png
 
Tip
When updating the Bugzilla product or component, do not forget to reset to the default assignee


Useful Links

Debug package names for several distributions

For every KDE application it is recommended to install the debug information for "kdelibs" and "qt4"

Package Ubuntu/Debian OpenSuse Fedora Mandriva
kdelibs kdelibs5-dbg kdelibs4-debuginfo kdelibs-debuginfo kdelibs4-debug
qt libqt4-dbg libqt4-debuginfo qt-debuginfo qt4-debug
kdebase (KDE base applications) kdebase-dbg, kdebase-runtime-dbg, kdebase-workspace-dbg kdebase4-debuginfo, kdebase4-runtime-debuginfo, kdebase4-workspace-debuginfo kdebase-debuginfo, kdebase-runtime-debuginfo, kdebase-workspace-debuginfo kdebase4-debug, kdebase4-runtime-debug, kdebase4-workspace-debug
General example for every KDE "MODULE" kdeMODULE-dbg kdeMODULE4-debuginfo kdeMODULE-debuginfo kdeMODULE4-debug
Phonon (multimedia subsystem) phonon-dbg libphonon4-debuginfo / phonon4-debuginfo phonon-debuginfo phonon-debug

For a detailed list of distribution naming scheme examples you can look at How to obtain debug packages for every distribution.

Glossary

  • Testcase: custom file that triggers a bug in the application. A testcase can also be a custom code snippet or a set of steps.

Content is available under Creative Commons License SA 4.0 unless otherwise noted.