Contribute/Bugsquad/Guide To BugTriaging - Revision history

Mamarok: /* Setting Bugzilla fields (and re-assignation) */ add information about version

2013-04-17T06:16:03Z

‎Setting Bugzilla fields (and re-assignation): add information about version

Argonel: /* Adding new information (and requesting feedback) */

2013-04-09T09:05:03Z

‎Adding new information (and requesting feedback)

Manko10: /* Handling reports: What to do with a bug report */ Typos

2012-06-15T09:53:01Z

‎Handling reports: What to do with a bug report: Typos

Hns: /* General Considerations */

2012-02-19T16:43:16Z

‎General Considerations

Mamarok: /* Check the report quality (and ask for missing information) */ added Git for the revisions

2011-11-24T15:53:50Z

‎Check the report quality (and ask for missing information): added Git for the revisions

Nicolas17: /* Avoiding useless function calls */ monospaced font for class names and file names

2011-10-07T17:51:37Z

‎Avoiding useless function calls: monospaced font for class names and file names

Nicolas17: /* Identifying the first (useful) backtrace functions */ cleanup link on last sentence

2011-10-07T17:48:23Z

‎Identifying the first (useful) backtrace functions: cleanup link on last sentence

Nicolas17: /* Definition */ join last three sentences into a single paragraph.

2011-10-07T17:44:28Z

‎Definition: join last three sentences into a single paragraph.

Nicolas17: /* Definition */ use real formatting instead of asterisks, and unicode quotes

2011-10-07T17:43:44Z

‎Definition: use real formatting instead of asterisks, and unicode quotes

Seli: fix opensuse debug package names for phonon

2010-04-30T13:24:43Z

fix opensuse debug package names for phonon

@@ Line 295: / Line 295: @@
 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 a application version, you probably want to set the version in the Bugzilla field
+* '''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.
-* '''Priority''': we don't use this field in the KDE bug tracker
+* '''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.
 * '''Severity''': if the bug is important, critical or it causes data loss if should be set to "major" or "critical". If it is about a crash or a freeze it should be set to "crash". If it is any other kind of bug, it should be set to "normal". If it is a feature request (not a regression) it should be set to "wish".
 ** 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.

@@ Line 433: / Line 433: @@
 * 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.
-* 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)
+* 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.
 A template of comment for this situation could be:

@@ Line 91: / Line 91: @@
 =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 peace 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}}
-As KDE has too much 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 too 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.
 ==Identifying duplicates==

@@ Line 11: / Line 11: @@
 =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 others 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; otherwise you will end up with a headache.

@@ Line 287: / Line 287: @@
 * KDE Platform (and/or Software Compilation) version
 * If the bug is about a crash, request the version of the Qt library
-* If the reporter is using an development version, request the 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 platform 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)}}

@@ Line 229: / Line 229: @@
 '''Classes and functions to ignore in a backtrace''':
-* Kernel/GLibC functions (__kernel_vsyscall, raise, abort)
+* Kernel/GLibC functions (<tt>__kernel_vsyscall</tt>, <tt>raise</tt>, <tt>abort</tt>)
-* 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)
+* 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 (QMap, QList, QLinkedList, QVector, QStack, QQueue, QSet, QMap, QMultiMap, QHash, QMultiHash)
+* 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 deep core classes (QApplication, QCoreApplication, QBasicAtomicInt, QBasicAtomicPointer, QAtomicInt, QAtomicPointer, QMetaObject, QPointer, QWeakPointer, QSharedPointer, QScopedPointer, QMetaCallEvent)
+* 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 (qt_message_output, qt_message, qGetPtrHelper, (starting with) qt_meta_)
+* 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)===

@@ Line 222: / Line 222: @@
 {{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)}}
-If the first backtrace functions aren't available (they are not there, or there are "??" )then we can't proceed without requiring more information (a more complete backtrace) [http://techbase.kde.org/Contribute/Bugsquad/Guide_To_BugTriaging#Check_the_report_quality_.28and_ask_for_missing_information.29 Ask for more information]
+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).
 ===Avoiding useless function calls===

@@ Line 154: / Line 154: @@
 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 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 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”.
 ===Example===

@@ Line 150: / Line 150: @@
 ===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 was the application doing when it encountered the 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 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 other lines show the “way to the first function”.
 ===Example===

@@ Line 552: / Line 552: @@
 |  ''Phonon (multimedia subsystem)''
 |  phonon-dbg
-|  phonon4-debuginfo-x86 / libphonon4-debuginfo-32bit
+|  libphonon4-debuginfo / phonon4-debuginfo
 |  phonon-debuginfo
 |  phonon-debug