Chapter 5. Handling Bug Reports

In KDE, bugs are collected in a bug database, called KDE Bugs. KDE Bugs is a database of the Bugzilla-kind. Mainly KDE Bugs is web-based, but it uses emails for notifications. KDE Bugs has also an email interface with limited possibilities (especially you cannot create a bug report by email.)


Often KDE Bugs has some reach problems, in such cases, it can be useful to know that there is also a SSL access: (Of course, it does not work always, especially if KDE Bugs is overloaded.)

Bug reports are handled by their number. KDE Bugs handles wishes like bugs too, just with a different priority.

In KDE Bugs, a user needs to be registered to be able to write to bug reports (or to create new ones). Users are represented by their email address (but do not worry, KDE Bugs allows you to change your email address, in case you would need it). When not registered, a user has only a restricted read-only view of the bug reports.

Each time a bug report is modified, KDE Bugs sends an email to the emails linked to the bug report (bug reporter, the "maintainer", people having voted for the bugs, people having registered themselves in the CC list of the bug report). Also the notification is sent to the kde-bugs-dist mailing list.

The life of a bug report is that first it is created, getting the status UNCONFIRMED or NEW. (Unlike other Bugzilla-like databases, bug reports are seldom confirmed in KDE, as KDE has not a special team for it.) When the bug is fixed, the bug report's status is changed to RESOLVED/FIXED. There are also other possible RESOLVED state, for a duplicate (RESOLVED/DUPLICATE), for an invalid bug (RESOLVED/INVALID, e.g. if a reporter has reported the exact same bug more than once or if a question remains unanswered for more than a year), for stating that the bug report will not be fixed (RESOLVED/WONTFIX) or that the bug report cannot be reproduced at all (RESOLVED/WORKSFORME). The others states of bug are VERIFIED (QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Bugs remain in this state until the product they were reported against actually ships, at which point they become CLOSED) and CLOSED (The bug is considered dead, the resolution is correct. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED).

To be able to change properties of the bug report (including status), a user must have an "editing" capability. Please ask the Sysadmins to get it if you need it.

Translation bugs are in the "component" named "i18n", there is a "product" named "general" and there are other "products" for many language teams. (Your team can be added too, either as a private email address or with a mailing list address. Ask the Sysadmins to get it if you want it.) Mostly "component" and "product" are written together e.g. i18n/general .

The mail interface has, as written before, limited capabilities, but can be enough for many tasks, and also can avoid to have to wait on a crowded web site. The most simple address is of the form where nnnnnn is the (unpadded) bug number (example This simple form can be used by any user having an account on KDE Bugs, of course only when using the registered email address, not from another email address. Replying to a notification email of KDE Bugs produces such an email address too.

For users with "editing" capability, other email addresses are available (where nnnnnn is still the bug number). The main ones are:

  • and . They change the bug report's status to RESOLVED/FIXED

  • To re-open a bug (status REOPENED), you can use

  • To mark as RESOLVED/INVALID:

  • To mark as RESOLVED/WONTFIX:


  • To mark as RESOLVED/DUPLICATE: , where xxxxxx is the bug number of the original bug that is duplicated.