Cleaning up the Cruft in KDE’s Bugzilla

There are 42,000 open bugs in KDE’s Bugzilla.

We know this is a problem, and some steps have been taken recently to attempt to reduce this. Not long ago, Nate Graham proposed a cleanup of our plasma4 product, which closed 4,000+ bugs. Most of the bugs there were very old and no longer relevant, due to the introduction of Plasma 5 four years ago. While that was a good step in the right direction, we have many, many more products.

In fact, there are 741 “products” in the KDE Bugzilla.

bring-out-your-deadMany of those products are long dead. Projects that were brought under the KDE wing years ago, but have been abandoned and unmaintained for many years. Or, products that have been purposefully obsoleted in favor of a newer product name. Unfortunately, those Bugzilla products have been left open, allowing bug reports to be submitted, left to linger and clutter the database.

So we fixed that.

Nate and I worked together, building off of a list produced by Julian Schraner, of unmaintained, dead products. After a few days of verification, we were able to close 259 products and close 2,500+ bugs that were left lingering in those products. Now, when you create a new bug, those 259 are hidden, and only available in the “Browse” page.

So that is helpful, and we’ve seen a visible drop on the Bugzilla charts from these closures.

But what about the daily intake?

KDE receives 30+ new bugs per day.

The KDE developers do an excellent job, many of them triaging themselves, and resolving bugs quickly, attempting to hold back the onslaught. But it’s just too much, and we often have more new bugs opened than closed.

This causes terrifying charts such as this:

open bugs

The bugs pile up.

See those 27,000 UNCONFIRMED bugs? This is the reason I resurrected the KDE Bugsquad. The signal-to-noise ratio is much too low!

A good example of what the above chart should look like, is the one for Krita:


The signal-to-noise ratio here is much higher. Most bugs are CONFIRMED or NEEDSINFO from the reporter. Developers know which are real issues, and the bug reports have information from the reporters and the triagers in the comments.

We need to get the rest of the KDE products to look like this.

Let’s clean up the old cruft. I’m proposing the following actions to take:

  1. Close any additional unmaintained products that were missed. I have a list of a few that are questionable, and will require some additional investigation or emails. This step could close 2,000 bugs.
  2. Close NEEDSINFO bugs that have not had a response for 30 days. This would become a KDE Bugzilla policy. It cannot be expected to leave a bug open indefinitely, if the reporter will not provide the additional requested information. This is already a policy at many other projects such as The Document Foundation, Chromium, and Fedora. After a discussion regarding this on the kde-community mailing list, there appeared to be a consensus, so work has already begun. This step alone, will close almost 6,000 bugs.
  3. Request follow-up and potential closure of old crash reports. This would clean up old crash reports provided mostly by Dr. Konqi, that have sat untouched for several years. There is a good possibility the crash is no longer relevant in newer releases. This step would close over 3,800 bugs.
  4. Close old bugs that are beyond 10 years old in their last activity. This would get rid of the oldest abandoned bugs, some of which date back to 2002 or earlier! This step would close over 3,300 bugs.

Getting involved in the KDE Bugsquad is a great way to easily get involved. You only need a few minutes and the latest version of an app. Check out our Bug triaging guide to understand the process. It’s really easy!

You could help triage bugs with me!

Visit KDE’s Get Involved page for more information, or contact me!

13 thoughts on “Cleaning up the Cruft in KDE’s Bugzilla

    1. Haha, yeah the “All” products looks just as nice. But you can’t see the other colors there’s so many resolved! 🙂


  1. Great overall. However, I don’t much like this:

    “Close old bugs that are beyond 10 years old in their last activity.”

    Just because a bug is old doesn’t mean it isn’t relevant. A lot of bugs are old just because nobody did anything with them, and bumping is considered impolite from what I understand. For me it would be really disheartening to have posted a bug, have nothing happen with it from the KDE devs, then have it automatically closed solely for that reason without any chance for me to even respond.

    I would prefer to send out an automated message that asks if the bug is still relevant, then invoke the 30 days “NEEDSINFO” policy. That at least gives people a chance to save the bug if they want while still allowing obsolete bugs to be closed.


    1. Yes, that’s the general plan, I just kept the explanation short because I haven’t brought this up to kde-community yet. I’m sure it would be a comment first, with a waiting period like NEEDSINFO.


      1. In that case you can probably be less conservative and squeeze the number of years. What do you think?


      2. Unfortunately, I need to get follow-ups on lots of bugs one chunk at a time. Each bug may have 5-10 email addresses on it, so I could end up sending 20,000-40,000 emails just to follow up on 4,000 older bugs, which drives everyone crazy, and hits us for spam. So unfortunately, conservative is the only way to go. As those get dealt with, I’ll filter out other areas that we can revisit.


  2. Great initiative and post! And thanks for all the effort!
    I plan on trying to join the Bugsquad soon as well, but first I need a new PC (current one has Nvidia freeze problems under Linux) which is scheduled for next month 🙂
    Hopefully more people will come and contribute in the Bugsquad; KDE is so active nowadays, amazing!


    1. Thank you! I look forward to you coming onboard. Please feel free to reach out to me if you need any help getting signed up for seeing it out to triage.


  3. Finishing the well polished final assembly of KDE products is missing while on too many new ideas is already worked on. Eventually, the solid final assambly never takes place. By time it becomes forgotten where finishing wasn’t accomplished and it even becomes forgotten that finishing needs be accomplished. A KDE Bugsquad should therefore first care for the establishment of a proper quality consciousness. I suggest to implement thorough feature freeze periods.


  4. I am surprised to see I am not the only one to have problems with Dr Konqi. 🙂

    I can not even get it to compile … reported the same bug twice but it was not fixed. I guess nobody wants to fix dr. konqi. 😛

    Perhaps in the long run, a heroic soul could do a rewrite or create a new application that can tackle the use case that dr. konqi has. (The rest of the KDE software compiles, but dr konqi does not want to.)


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s