Bug Triaging

This is a modified version of a post by Boudewijn Rempt on krita.org: https://krita.org/item/ways-to-help-krita-bug-triaging/

There are many ways of helping Kdenlive, ranging from coding to writing tutorials, helping users on forums, to spreading the word and helping with fundraising. But let’s take a look at one task that is really important: bug triaging.

Now that there are so many Kdenlive users, and many new features, we’re getting lots of bug reports. And a lot of those bugs are specific to the reporter’s system. Or so it seems. Some bugs only happen with certain combinations of hardware, operating system, other installed software. Some bugs happen for everyone, but are rare because not that many people use a feature, and some bugs suddenly turn up because we’re human and we make mistakes.

And every report needs to be read, preferably by several people, who can try to determine:

  • whether they can trigger the bug — and in that case, confirm it
  • if they cannot understand the report, or determine that the report is incomplete — and in that case, ask for more information
  • if the bug has been reported before, and if so, close the bug as a duplicate of the earlier report.

We’re using KDE’s bugzilla to track bugs for Kdenlive. Bugzilla is an old-fashioned monster of a web application, but it’s what we have, and for now we’ll have to make it work for us! Here’s what you see when you search for open Kdenlive bugs:

Kdenlive bug triaging - bug list.png

Important bits of information are:

  • Component: does the bug relate to Documentation, Effects & Transtitions, Installation, Translation, User Interface, or Video Display & Export?
  • Status: UNCO means Unconfirmed. That means that we either haven’t tried to reproduce the bug, or we couldn’t reproduce it.
  • Summary: a short description of the issue

As you can see, we really need help! JB is also the maintainer of the project, developer and manager. [Together with Vincent… INPUT NEEDED ON THIS PART], they’re trying to triage all reported bugs, and we’re not managing to reply on time.

That’s where you come in! If you’re a reasonably experienced Kdenlive user and want to help out, here’s how to get ready and set up!


Get a Bugzilla Account

Go to https://bugs.kde.org and select “Create new Account”

Kdenlive bug triaging - new account.png

Complete the registration forms, and click on the confirmation link in the email you get sent.

Kdenlive bug triaging - confirm email.png


Setup Email Notifications

Log in to bugzilla and click on the Preferences link at the top, then “Email Preferences”. Bugzilla can send a lot of email, but fortunately it includes a number of special headers that make it easy to filter bug mail into special folders of your inbox. There are two steps – first are the general email preferences:

Kdenlive bug triaging - email preferences.png

And then there’s the important bit, that makes sure you get email for all bugs that are about Kdenlive. Add the user “kdenlive-bugs-null@kde.org” to the list of User Watches:

[here we need a kdenlive equivalent – there is no “kdenlive-bugs-null@kde.org” as far as I’m aware – here is the krita screenshot: https://krita.org/wp-content/uploads/2016/03/Spectacle.wZ7342.png]

Now you will get mail whenever anything happens to a Kdenlive bug. Using the special bugzilla headers, you can sort all the mail ready for handling:

X-Bugzilla-Reason: None X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: AssignedTo kdenlive-bugs-null@kde.org X-Bugzilla-Product: Kdenlive X-Bugzilla-Component: X-Bugzilla-Version: 16.04 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: [jb@kdenlive.org] X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: NOR X-Bugzilla-Assigned-To: kdenlive-bugs-null@kde.org X-Bugzilla-Target-Milestone: — X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter

For instance, you could split your bug mail according to whether it’s a new bug, a changed bug, a new wish, a changed wish, or a reply to a needs-info query.


Triage a Bug

And then when a bug lands in your inbox, you can open it in bugzilla and triage it. There are a couple of steps here:

  1. Check if the severity is “wish”, if so, leave alone. Wish bugs are special.
  2. Check whether it’s a duplicate, if so, close it.
  3. Check whether the subject makes sense and mentions the most pertinent information, if not, update it
  4. Check whether the version isn’t too old. At this moment, we don’t try to fix bugs for 9.x anymore, and after 16.04 is released,

if a bug is reported for 9.x the bug should be marked as NEEDSINFO and the user asked to try to reproduce the issue with 16.04 Thank the reporter for her/his bug report. Keep in mind that reporting a bug can be scary enough, especially for new users, and that it is also a certain amount of effort. Bug reporters are awesome contributors, too!

These are the preliminaries: now then the real work starts. Trying to reproduce the bug. At first, you won’t be able to close bugs; so at first all you can do is add comments to the bug report. If you’ve done that a couple of times, you’ll have learned how the system works and gotten a feel for what should be done with new bugs. That’s the moment to ask JB [jb@kdenlive.org] or Vincent [vpinon@kde.org] for more powers!

It’s easy to reproduce: add any notes on how you reproduced the issue, on your distribution, version of Kdenlive, hardware and set the bug to CONFIRMED. There is not enough information to reproduce the bug: set the bug to NEEDSINFO and ask the reporter for more information.
You cannot reproduce the bug even though the report is complete and you can follow all the steps: Note that you cannot reproduce the bug and ask the reporter to reproduce. Set the bug to NEEDSINFO and wait. If the reporter answers that they cannot reproduce either, close the bug as WORKSFORME.
You cannot reproduce the bug but suspect that that’s because it’s already fixed: add a comment to the bug but don’t change the status yet. You suspect that the reporter simply doesn’t realize that they are using Kdenlive in the wrong way, for instance by mixing 48kHz & 44.1kHz audio. Point the reporter to the manual and close with NEEDSINFO. If the reporter replies that that is the case, we can close the bug. The bug is about an issue with a hardware device, eg ShuttlePro. [what should be done here? anything diffferent?]

And that’s it, really. Now start triaging bugs and earn our undying gratitude! Help with bug triaging is a real and lasting contribution to Kdenlive!