With bug number 100,000 reported, the hard-working KDE bug tracking system reached a milestone today. However, not everyone knows what goes on behind the scenes and how to help. In this article, I take a short look at using the bug reporting system, and how you can help KDE improve.
To get such a large number of reports from users and developers of the
software takes some time. However, reports have been entering the
system since the early days of KDE back at the start of 1999. With
such an impressive amount of data in the bug database, it's worth
taking a look at how it's all organized and kept running smoothly, and
what you can do to help.
More than you might think
The KDE bug tracker doesn't just contain reports of crashes and
misfeatures in applications, but plenty of other information. If
there's a feature you'd like to see in KDE which others would find
useful, you can file a 'wishlist' bug requesting it. We'll look at the
best way to report wishlist requests shortly, but just keep this in
mind for the moment. And KDE isn't just code! You can also file a bug
against documentation if you find a problem with it - just use the
docs product. And the polished look of KDE is important too:
you can report problems with icons, wallpapers or splash screens in the
With dozens of bugs reported each day (as I write this, the system
tells me that 105 bugs were reported today alone), maintaining and
organising all that information is no small task. Although many KDE
developers put a lot of time into dealing with bugs, it's not always
the most efficient way for them to spend their limited time. And
that's where you can help. Bug triage is a simple but effective way to
get involved with KDE. The definitive guide is the KDE
Quality Team bug triage howto, but here are some tips to get you
- Choose an application (or applications!) that you like and are familiar with, and
watch bugs for that application. That way, you can judge more easily whether
the bug is valid, and you'll rapidly become familiar with the bugs
that are already reported.
- Running a CVS HEAD or stable branch (KDE_x_x_BRANCH) version of
KDE will allow you to check whether bugs have been fixed in the
development version of KDE. It's a worthwhile payoff for the time it
takes to compile a CVS version.
- Consider working on bug reports for the Konqueror HTML renderer (KHTML). They're quite easy to test,
and the quality team howto gives some good tips on how to produce test
cases and so on.
If you'd like to help with bug triage, but aren't sure where to
start, drop the KDE Quality Team a line at firstname.lastname@example.org. Remember,
it doesn't necessarily take a lot of your time, but can really help
KDE to improve.
Getting the most out of the system
Despite the hard work of all the KDE developers, bugs sometimes do
hamper your work in KDE. But, as a user, you're in a position to be
able to do something about it. The first line of attack is to file a
bug report on bugs.kde.org. There
are some easy ways to make sure that your bug report is as useful as
possible. Following them makes life easier for the developer reading
the report, and makes it more likely that the bug will be fixed, so
The definitive guide to effective bug reporting is by Simon Tatham,
prosaically called How to
Report Bugs Effectively. I won't repeat everything he says, but
just note some things that are particularly relevant to KDE.
- Check carefully that the bug hasn't already been
reported. Bugzilla has powerful query tools for this, so make sure you
use them when reporting a bug. If the bug has already been reported,
read the comments to see if there's anything useful you can add (for
example 'this bug also occurs in the latest cvs version').
- Work with the developer, not against him or her. It might
seem like you're on opposite sides, finding problems in a programmer's
code, but you have the same aim - fixing the bug. Provide any
information about your system that the developer asks for, and test
any workarounds that he or she asks for.
- If you're filing a wishlist bug, make sure that you're clear about
what you are requesting. A simple graphic or a mockup of what you'd
like can sometimes speak louder than words (but put the words in
In conclusion, the KDE bug database is a powerful tool for both
users and developers, and a great way for new contributors to give
something back to the KDE project. With a few simple guidelines, it
can be made the most productive possible, with very little pain. So
get reporting and triaging!