Wednesday, March 22, 2006

I've got a little bit of free time, so here's the first in what will
hopefully become a series of hints and tips about getting involved in
KDE without having to learn C++.

Today's topic is bug triage. Around 80 new bugs and wishlist items are
filed in KDE's bug tracking system
every day, and, while application and library maintainers try to look
at all of the ones reported for their application, their job is a lot
easier if someone else has already gone through and removed the
duplicates, asked the reporter for any additional information that's
useful, and noted which bugs can be reproduced.

The really nice thing about bug triage is that it comes in very small,
bite-sized chunks: each bug report probably takes a few minutes to
look through, so you can spend ten minutes a day on bug triage (on
your coffee break!), and be able to do something useful - something
that isn't so practical with some other ways of helping KDE.

The main reference for bug triaging, which I'd thoroughly recommend,
is the
bugs howto
. That'll give you some pointers for getting started,
and tell you a little about how the bug tracking system works, what
the different bug statuses mean, and so on.

So, once you've got an account on and read the howto, what do you do next? The first thing to do is
decide which bugs to concentrate on: do you want to look just the bugs
for one or two applications, or take an overview of al bugs that are
reported? If you're a long term KDE user, and are a little bit
familiar with the internals, then taking an overview might be for you:
you'll be able to see when bugs are filed against the wrong KDE
component, and suggest what other parts of KDE could be relevant to
the bug. If you're not familiar with the internals of KDE, you can
still do bug triage! Just pick an application you use a lot, or
particularly like, and concentrate on the bugs that are reported for
that application.

Let's say you decide to concentrate on bugs in one particular app. You
can use the query page to
display all the open bugs for that application, or just the bugs that
have been opened in the last few days. Take a look at each bug, with
the aim of determining whether or not the behaviour that the reporter
described is really a bug, and if so, making it easier for the
developer to fix it. Put yourself in the shoes of the developer - what extra information will they need to be able to
start fixing the bug?

Some things to do:

  • First, try to reproduce the behaviour that the reporter has
    described. Add a comment to say whether you could reproduce the bug,
    noting your KDE version and distribution. If you don't understand the
    description, ask for clarification - if you can't understand what the
    reporter means, the developer probably won't be able to either.

  • If you can reproduce the behaviour, think of ways to narrow down
    the cause: Imagine that an app crashes when you save a document. What
    about selecting Save from the File menu? What about pressing Ctrl+S?
    Does it happen for any document, or just certain documents (perhaps
    certain file formats)? What about local vs remote files? This is where
    you get to use your imagination a little bit, since every bug report is

  • Try to find out whether the bug is related to a problem with
    config files: trying to reproduce the bug with a newly created user
    (and asking the reporter to do the same) is a good way to test

Those are some common, simple things that I can think of. As you get
more experienced, you'll find other tips n' tricks that are useful,
especially if you choose to concentrate on just one application.

So, in 20-second summary:

Bug triage

Why's it useful? It makes bug hunting and fixing easier for
developers, so more bugs get fixed.

Why choose bug triage instead of ...? It doesn't take much time
to look over a bug, so it comes in nice small chunks

What skills do I need to do it? Not much, just a bit of
patience and sometimes some perseverance.

Saturday, March 11, 2006


So I said I'd write some mini-howtos on non-coding ways to get involved with KDE. Kevin Krammer has beaten me to it, and he has some good information and insights.

I don't have time to write a full mini howto, but I have a neat story about bug triage, and how the contributions of non-coders and coders can all come together quite nicely.

It began (for me at least) with flicking through the bug reports, looking for anything I could usefully comment on. I noticed that bug 122218 and bug 122158 looked quite similar, so I added a comment to each bug to say so. Lubos fixed the second bug, and added a comment to the first to note how he'd done it. Enter Ismail Onur Filiz, who, on finding Lubos' explanation of the fix, codes up a patch. It's reviewed and applied, and there's one less bug in KMail :-).

I'm quite pleased with that story, since it shows how non-coding contributions can help things happen, even if they're not directly producing the end result, and it makes me feel that my occasional bug triage attempts are useful.