Bugsquad/Howto: Difference between revisions

From KDE Community Wiki
No edit summary
(Bring article up to date)
Line 1: Line 1:
The main communication tool between developers and users, and the main quality tool is the KDE bugs and wishes database. The database is implemented using the [http://www.bugzilla.org/about.html Bugzilla] tool for tracking bugs and wishes, developed initially for the Mozilla web browser. [http://bugs.kde.org/] is the  the web front end implementation of KDE's Bugzilla, and the main place to go when managing bugs, but there are other front ends: the KBugBuster, from the kdesdk module and the e-mail interface, used to add comments, change bugs status, etc...
The main communication tool between developers and users, and the main quality tool is the KDE bugs and wishes database. The database is implemented using the [https://www.bugzilla.org/about/ Bugzilla] tool for tracking bugs and wishes, developed initially for the Mozilla web browser. KDE's Bugzilla instance is reachable via [https://bugs.kde.org/ bugs.kde.org].


<p>Many bug reports are filed daily, especially after releases. There are too many to be handled by the developers, so the amount of open reports increases over time. Additionally old bug reports have to be revisited regularly to see if they still apply to the current version. Reviewing the bugs database also give you insight about the most needed features and most pernicious bugs, allowing you to point them, and the developers to actually fix bugs or spend time to add new features to KDE, instead of managing bugs.</p>
Many bug reports are filed daily, especially after releases. There are too many to be handled by the developers, so the amount of open reports increases over time. Additionally, old bug reports have to be revisited regularly to see if they still apply to the current version. Reviewing the bugs database also gives you insight about the most needed features and most pernicious bugs, allowing you to point them out. This allows developers to spend more time on actually fixing bugs and to add new features instead of just managing bug reports.


<p>Always direct users to the KDE bug tracker system to discuss bugs and wishes, because this way issues will not be forgotten. If the point is a bit more polemic, it is sensible to start a discussion in the [http://www.kde.org/mailinglists/ application mailing list] or in [http://mail.kde.org/mailman/listinfo/kde-usability KDE usability mailing list], but instruct them to start by [http://bugs.kde.org/wizard.cgi filing the bug], because by [http://bugs.kde.org/quicksearch.html searching for similar bugs or wishes] they may find answers or insight.</p>
Always direct users to the KDE bug tracker system to discuss bugs and wishes, because this way issues will not be forgotten. If the point is a bit more polemic, it is sensible to start a discussion in the [http://www.kde.org/mailinglists/ application mailing list] or in [http://mail.kde.org/mailman/listinfo/kde-usability KDE usability mailing list], but instruct them to start by [http://bugs.kde.org/wizard.cgi filing the bug], because by [http://bugs.kde.org/quicksearch.html searching for similar bugs or wishes] they may find answers or insight.


<h3>Before Starting</h3>
== Before Starting ==


<p>To start, [http://bugs.kde.org/createaccount.cgi open an account on bugs.kde.org] if you don't have one. The database records not only the bugs and wishes status, but also related discussions, screenshots, patches, etc.. turning it to a very complete source of information. Please try the following pages at [http://bugs.kde.org/ bugs.kde.org], to get used to KDE bugzilla capabilities. The KBugBugster is also useful, but less flexible.</p>
To start, [https://bugs.kde.org/createaccount.cgi open an account on bugs.kde.org] if you don't have one. The database records not only the bugs and wishes status, but also related discussions, screenshots, patches, etc.. turning it to a very complete source of information. Please try the following pages at [http://bugs.kde.org/ bugs.kde.org], to get used to KDE bugzilla capabilities.


* [http://bugs.kde.org/quicksearch.html Simple search form]
* [https://bugs.kde.org/query.cgi?format=specific Simple search form]
* [http://bugs.kde.org/query.cgi Advanced search form]
* [https://bugs.kde.org/query.cgi?format=advanced Advanced search form]
* [http://bugs.kde.org/wizard.cgi New wishes/bugs wizard]
* [https://bugs.kde.org/enter_bug.cgi?format=guided New wishes/bugs wizard]


<p>At the beginning, you will only be able to comment on bug reports which are not your own. Only after acquiring more knowledge on the application and on KDE Bugzilla system, you may ask for rights to confirm bug reports and close non verifiable ones.</p>


<p>You need a current installation in order to be able to test if a bug is still uptodate. This means you should either test with the master branch, that is the latest development-version of the product. See [[LINK TO BUILDING FROM SOURCE]]
At the beginning, you will only be able to comment on bug reports which are not your own. Only after acquiring more knowledge on the application and on KDE Bugzilla system, you may ask for rights to confirm bug reports, or close them if they cannot be verified.
</p>


<p>Also it is important to have compile with debug information. A program compiled with debug information is bigger and runs slower, but provides invaluable information to the developers when applications crash, as they are able to locate where in the source code it crashed, and sometimes even why. Whenever an application crashes, the KDE crash handler appears. You can now retrieve the backtrace information to add to a bugreport.</p>
You need a current installation in order to be able to test if a bug is still valid. You should test with the latest development version of a product, which is on the master branch for most KDE modules. [[Guidelines_and_HOWTOs/Build_from_source|This guide]] helps you to build these development versions.


<h3>Managing Reports</h3>
When building KDE modules for bug triaging purposes, make sure to include debug symbols, assertions and the like. Since KDE modules usually use the [https://cmake.org/ CMake] build system, this can be achieved by setting the [https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html CMake build type] to Debug (or, in rare cases, FullDebug). A program compiled with debug information is bigger and runs slower, but provides invaluable information to the developers when applications crash, as they are able to locate where in the source code it crashed, and sometimes even why. Whenever an application crashes, the KDE crash handler provides you with a dialog to report the crash. This dialog can be used to easily extract a stack trace that led to crash, and crashes reported using this dialog always include the corresponding stack trace.


<p>The main tool for bug triage is knowledge of your application. You will learn that you don't need to be a developer to have a good understanding of it: reading bug reports and comments about them, writing documentation or working with the application's user interface will do the trick.</p>
== Managing Reports ==


<p>You should always start by stating your opinion in the bug reports and letting the developers take the appropriate action. If you feel you are ready to manage bugs effectively, know well the application and have a bit experience with bugzilla, it is time to ask for permissions. The [mailto:[email protected] Quality Team mailinglist], the [https://bugs.kde.org/enter_sysadmin_request.cgi KDE system administrator], or the mailinglist of the application you are working with, are the right places to ask for it. The developers will probably be happy to have someone working with them, and in the end of the day it is your own reputation as a good contributor that is in the line, as developers will still watch what you are doing. Some of the task below require these permissions.</p>
The main tool for bug triage is knowledge of your application. You will learn that you don't need to be a developer to have a good understanding of it: reading bug reports and comments about them, writing documentation or working with the application's user interface will do the trick.


<p>A good way to start is checking if bugs are still valid:</p>
You should always start by stating your opinion in the bug reports and letting the developers take the appropriate action. If you feel you are ready to manage bugs effectively, know your way around the application and have enough experience with bugzilla, it is time to ask for permissions. Ideally, you would [https://go.kde.org/u/systickets issue a KDE SysAdmin ticket] for that, and include some links to bugs you commented on to demonstrate that you know what you are doing. Alternatively, you can ask in [irc://irc.freenode.net/#kde-sysadmin #kde-sysadmin on freenode]. The developers will probably be happy to have someone working with them, and in the end of the day it is your own reputation as a good contributor that is in the line, as developers will still watch what you are doing. Most of the tasks below require these permissions.
 
A good way to start is checking if bugs are still valid:


* Believe the reporter: if you cannot reproduce a new bug, first ask for more context information, then think about closing it or asking to close it.
* Believe the reporter: if you cannot reproduce a new bug, first ask for more context information, then think about closing it or asking to close it.
* The bug may be triggered by a combination of factors, or the bug may be fixed in the main branch, but not in the stable branch (if so, ask in the bug report for a backport. If it is not doable, the developers will say so).
* The bug may be triggered by a combination of factors, or the bug may be fixed in the main branch, but not in the stable branch. If so, ask in the bug report for a backport. If it is not doable, the developers will say so.
* Add any additional information you can give, e.g. backtrace, additional observations, how to (better) reproduce the faulty behavior or simply add with which day's version the bug still appears.
* Add any additional information you can give, e.g. stack trace, additional observations, how to (better) reproduce the faulty behavior or simply add with which day's version the bug still appears.
* If you can reproduce an UNCONFIRMED bug, please write that in the bugreport and change its status to NEW.
* If you can reproduce an UNCONFIRMED bug, please write that in the bugreport and change its status to CONFIRMED.
* If a program hangs, you can &quot;kill -SIGSEGV Processid&quot; the process to get a backtrace.
* If a program hangs, you can <code>kill -SIGSEGV <process id></code> the process to get a stack trace.
* Check if the report is filed into the correct product and component category too. KDE is a very modular, and massively reuse code, and sometimes is hard even for the developers to detect in which component the bug is, so be careful. If the report is not already assigned to some other developer than the current component owner, <strong>make sure to select the &quot;Reassign bug to owner of selected component&quot; when moving a report</strong>. If a report is filed into a category where there is no single maintainer/active developer and you know which developer is responsible or works on the code (a look into the source or reading kde-cvs mailing list can help), you may assign a bug report to him/her directly.
* Check if the report is filed into the correct product and component category. KDE is very modular, and massively reuses code. It can be hard at times even for the developers to detect which component a bug is in, so be careful. If the report is not already assigned to some other developer than the current component owner, '''make sure to select the &quot;''Reassign bug to owner of selected component''&quot; ''' when moving a report. If a report is filed into a category where there is no single maintainer/active developer and you know which developer is responsible or works on the code, you may assign a bug report to him/her directly. Active developers can regularly be found by looking at the version control log, usually via <code>git log</code> or on [https://quickgit.kde.org/ quickgit.kde.org].
* Check if a report describes an error already described in another closed or open report: Resolve it as DUPLICATE with reference to the prior report.
* Check if a report describes an error already described in another closed or open report: Resolve it as DUPLICATE with reference to the prior report.
* Check if the same report was submitted more than one time. Please close the identical bug (the one with the highest number) as INVALID and not as DUPLICATE because otherwise they show up wrongly in the most frequently reported bugs statistics.
* Check if the same report was submitted more than one time. Please close the identical bug (the one with the highest number) as INVALID and not as DUPLICATE because otherwise they show up wrongly in the most frequently reported bugs statistics.


<p>Browser (Konqueror) bugs are usually very easy to check and there are lots of them:</p>


* Add &quot;(regression)&quot; to the title if the page was correctly rendered in a previous stable release.
You probably want to read the [https://bugzilla.readthedocs.io/en/5.0/using/index.html Bugzilla User Guide], which also documents the [https://bugzilla.readthedocs.io/en/5.0/using/editing.html#life-cycle-of-a-bug Life Cycle of a Bug] in a comprehensive diagram. Custom fields of KDE's Bugzilla instance are described [https://bugs.kde.org/page.cgi?id=fields.html here].
 
Browser (Konqueror) bugs are usually very easy to check and there are lots of them:
 
* Add <tt>[regression]</tt> to the title if the page was correctly rendered in a previous stable release.
* It's a good idea to put the site into the title where an error was encountered to ease duplicate spotting.
* It's a good idea to put the site into the title where an error was encountered to ease duplicate spotting.
* A parallel installation of a Gecko-based browser and Opera can give you an idea how a web page probably should look like.
* A parallel installation of a Gecko-based browser and Opera can give you an idea how a web page probably should look like.
* Try to generate a stripped down testcase of a faulty rendered webpage. Add &quot;(testcase)&quot; to the title if a testcase is attached to the bug report.
* Try to generate a stripped down testcase of a faulty rendered webpage. Add <tt>[testcase]</tt> to the title if a testcase is attached to the bug report.
* If a webpage doesn't exist any longer or was obviously rewritten and there was no testcase provided, close the report as WONTFIX.
* If a webpage doesn't exist any longer or was obviously rewritten and there was no testcase provided, close the report as WONTFIX.
* If the reporter or a comment mentions that a page works fine in Safari, it can help the developers to note that in the title too.
* If the reporter or a comment mentions that a page works fine in Safari, it can help the developers to note that in the title too.


<p>Check if the severity is appropriate, but if you don't agree, state so in the bugreport. Let the maintainer change the severity, as it is used by them to remind to fix crucial issues.</p>


<p>Check if the title contains a good summary, e.g. feature requests titled &quot;Feature wanted&quot; don't help when glancing over the report list. If a patch is provided add &quot;(patch)&quot; to the title.</p>
Check if the severity is appropriate, but if you don't agree, state so in the bugreport. Let the maintainer change the severity, as it is used by them to remind to fix crucial issues.


<p>Note: Don't use the &quot;Change Several Bugs at Once&quot; feature for moving reports. There is a bug in Bugzilla which confirms every reports which gets moved.</p>
Check if the title contains a good summary. Feature requests titled &quot;Feature request&quot; don't help when glancing over the report list. If a patch is provided, add <tt>[patch]</tt> to the title.


<p>The <strong>KDE Bugsquad</strong> coordinates bug triage efforts as well as organising regular bug-days where many people work together to clearup all the bugs for a particular program. Bug-days are an excellent oppurtunity for making your first steps in contributing to KDE, and there are always plenty of experienced bug-busters on hand to help you with any difficulties you may have. For more information, see the [[Bugsquad | Bugsquad pages]]</p>
The '''KDE Bugsquad''' coordinates bug triage efforts as well as organising regular bug days where many people work together to clearup all the bugs for a particular program. Bug days are an excellent oppurtunity for making your first steps in contributing to KDE, and there are always plenty of experienced bug busters on hand to help you with any difficulties you may have. For more information, see the [[Bugsquad|Bugsquad pages]].


This article originally from Carlos Leonhard Woelz -- http://websvn.kde.org/trunk/www/sites/quality/develop/howto/howtobugs.php?revision=1044461&view=markup&pathrev=1100000
This article originally from Carlos Leonhard Woelz -- http://websvn.kde.org/trunk/www/sites/quality/develop/howto/howtobugs.php?revision=1044461&view=markup&pathrev=1100000


[[Category:Needs Attention]]
[[Category:Needs Attention]]

Revision as of 13:27, 6 September 2016

The main communication tool between developers and users, and the main quality tool is the KDE bugs and wishes database. The database is implemented using the Bugzilla tool for tracking bugs and wishes, developed initially for the Mozilla web browser. KDE's Bugzilla instance is reachable via bugs.kde.org.

Many bug reports are filed daily, especially after releases. There are too many to be handled by the developers, so the amount of open reports increases over time. Additionally, old bug reports have to be revisited regularly to see if they still apply to the current version. Reviewing the bugs database also gives you insight about the most needed features and most pernicious bugs, allowing you to point them out. This allows developers to spend more time on actually fixing bugs and to add new features instead of just managing bug reports.

Always direct users to the KDE bug tracker system to discuss bugs and wishes, because this way issues will not be forgotten. If the point is a bit more polemic, it is sensible to start a discussion in the application mailing list or in KDE usability mailing list, but instruct them to start by filing the bug, because by searching for similar bugs or wishes they may find answers or insight.

Before Starting

To start, open an account on bugs.kde.org if you don't have one. The database records not only the bugs and wishes status, but also related discussions, screenshots, patches, etc.. turning it to a very complete source of information. Please try the following pages at bugs.kde.org, to get used to KDE bugzilla capabilities.


At the beginning, you will only be able to comment on bug reports which are not your own. Only after acquiring more knowledge on the application and on KDE Bugzilla system, you may ask for rights to confirm bug reports, or close them if they cannot be verified.

You need a current installation in order to be able to test if a bug is still valid. You should test with the latest development version of a product, which is on the master branch for most KDE modules. This guide helps you to build these development versions.

When building KDE modules for bug triaging purposes, make sure to include debug symbols, assertions and the like. Since KDE modules usually use the CMake build system, this can be achieved by setting the CMake build type to Debug (or, in rare cases, FullDebug). A program compiled with debug information is bigger and runs slower, but provides invaluable information to the developers when applications crash, as they are able to locate where in the source code it crashed, and sometimes even why. Whenever an application crashes, the KDE crash handler provides you with a dialog to report the crash. This dialog can be used to easily extract a stack trace that led to crash, and crashes reported using this dialog always include the corresponding stack trace.

Managing Reports

The main tool for bug triage is knowledge of your application. You will learn that you don't need to be a developer to have a good understanding of it: reading bug reports and comments about them, writing documentation or working with the application's user interface will do the trick.

You should always start by stating your opinion in the bug reports and letting the developers take the appropriate action. If you feel you are ready to manage bugs effectively, know your way around the application and have enough experience with bugzilla, it is time to ask for permissions. Ideally, you would issue a KDE SysAdmin ticket for that, and include some links to bugs you commented on to demonstrate that you know what you are doing. Alternatively, you can ask in #kde-sysadmin on freenode. The developers will probably be happy to have someone working with them, and in the end of the day it is your own reputation as a good contributor that is in the line, as developers will still watch what you are doing. Most of the tasks below require these permissions.

A good way to start is checking if bugs are still valid:

  • Believe the reporter: if you cannot reproduce a new bug, first ask for more context information, then think about closing it or asking to close it.
  • The bug may be triggered by a combination of factors, or the bug may be fixed in the main branch, but not in the stable branch. If so, ask in the bug report for a backport. If it is not doable, the developers will say so.
  • Add any additional information you can give, e.g. stack trace, additional observations, how to (better) reproduce the faulty behavior or simply add with which day's version the bug still appears.
  • If you can reproduce an UNCONFIRMED bug, please write that in the bugreport and change its status to CONFIRMED.
  • If a program hangs, you can kill -SIGSEGV <process id> the process to get a stack trace.
  • Check if the report is filed into the correct product and component category. KDE is very modular, and massively reuses code. It can be hard at times even for the developers to detect which component a bug is in, so be careful. If the report is not already assigned to some other developer than the current component owner, make sure to select the "Reassign bug to owner of selected component" when moving a report. If a report is filed into a category where there is no single maintainer/active developer and you know which developer is responsible or works on the code, you may assign a bug report to him/her directly. Active developers can regularly be found by looking at the version control log, usually via git log or on quickgit.kde.org.
  • Check if a report describes an error already described in another closed or open report: Resolve it as DUPLICATE with reference to the prior report.
  • Check if the same report was submitted more than one time. Please close the identical bug (the one with the highest number) as INVALID and not as DUPLICATE because otherwise they show up wrongly in the most frequently reported bugs statistics.


You probably want to read the Bugzilla User Guide, which also documents the Life Cycle of a Bug in a comprehensive diagram. Custom fields of KDE's Bugzilla instance are described here.

Browser (Konqueror) bugs are usually very easy to check and there are lots of them:

  • Add [regression] to the title if the page was correctly rendered in a previous stable release.
  • It's a good idea to put the site into the title where an error was encountered to ease duplicate spotting.
  • A parallel installation of a Gecko-based browser and Opera can give you an idea how a web page probably should look like.
  • Try to generate a stripped down testcase of a faulty rendered webpage. Add [testcase] to the title if a testcase is attached to the bug report.
  • If a webpage doesn't exist any longer or was obviously rewritten and there was no testcase provided, close the report as WONTFIX.
  • If the reporter or a comment mentions that a page works fine in Safari, it can help the developers to note that in the title too.


Check if the severity is appropriate, but if you don't agree, state so in the bugreport. Let the maintainer change the severity, as it is used by them to remind to fix crucial issues.

Check if the title contains a good summary. Feature requests titled "Feature request" don't help when glancing over the report list. If a patch is provided, add [patch] to the title.

The KDE Bugsquad coordinates bug triage efforts as well as organising regular bug days where many people work together to clearup all the bugs for a particular program. Bug days are an excellent oppurtunity for making your first steps in contributing to KDE, and there are always plenty of experienced bug busters on hand to help you with any difficulties you may have. For more information, see the Bugsquad pages.

This article originally from Carlos Leonhard Woelz -- http://websvn.kde.org/trunk/www/sites/quality/develop/howto/howtobugs.php?revision=1044461&view=markup&pathrev=1100000