Kdenlive/Workgroup/Triaging
Some parts of this page are based on https://krita.org/en/item/ways-to-help-krita-bug-triaging/
Introduction
With 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, and 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.
Every bug report needs to be read, preferably by several people, who can try to determine:
- whether they can reproduce 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.
The goal is to save developers from doing this, which helps them fix bugs faster, and use their time to develop new features for Kdenlive instead of doing bug triage. 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! Help with bug triaging is a real and lasting contribution to Kdenlive! If you benefit from the work others did on Kdenlive, it is a great opportunity to give something back to the project!
Kdenlive bugs are tracked on KDE's Bugzilla instance, under the Kdenlive product.
Overview on Kdenlive Bugs
- Open bug overview based on Status (REPORTED bugs that need triage)
- Chart: Open bugs over time (only accessible with "contributor" permissions)
Preparations
Before you can start, you need to create an account on the bug tracker (Note: the bug tracker is not connected to KDE Identity / MyKDE): Go to https://bugs.kde.org and select . Complete the registration forms, and click on the confirmation link in the email you get sent.
After you have created your account, you should read the general instructions on KDE bug triaging at Guidelines and HOWTOs/Bug triaging.
Triaging
This section summarizes what you've learned from Guidelines and HOWTOs/Bug triaging, and gives you some further instructions for bug triaging in the context of Kdenlive.
These are the basic steps for triaging a bug:
- Thank the reporter for the 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!
- Check if it’s a duplicate. If so, close it via the function. Make sure that the bugs are truly the same before doing this, you might need more info.
- Check that the summary (bug title) makes sense, and mentions the most pertinent information. If not, update it.
- Check that the version isn’t too old. We don’t try to fix bugs for version older than a year. If the bug is reported for an old version, mark it as NEEDSINFO, and ask the reporter to try to reproduce the issue with the latest version available from here.
- Check if the bug is a feature request. If so, see section below.
- Otherwise, try to reproduce the bug:
- If there is not enough information to reproduce the bug: set the bug to NEEDSINFO and ask the reporter for more information.
- If you can reproduce the bug: add any extra notes on how you reproduced the issue, on your distribution, version of Kdenlive, hardware and set the bug to CONFIRMED.
- If you cannot reproduce the bug, even though the report is complete, and you can follow all the steps: Let the reporter know that you cannot reproduce, ask them to try again, and set the bug to NEEDSINFO. If the reporter answers that they cannot reproduce anymore, close the bug as WORKSFORME. Keep in mind that a bug can be related to packaging issues with a specific package type (Flatpak, Appimage,…), a specific OS, or other factors of the user's environment. If you can not reproduce a bug, it doesn't necessarily mean the bug does not exist. Try reproducing it in all different package types, if you can.
- If 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.
- If 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.
| Tip: Identify Upstream Issues |
|---|
If you want to check if a bug is an upstream issue with Kdenlive's media engine MLT, try to play the *.kdenlive project or media file with the melt command line tool, like this melt <project-with-bug>.kdenlive. Another option is to check if the bug exists in Shotcut video editor, which also uses MLT. MLT bugs should be reported upstream at https://github.com/mltframework/mlt/issues |
You can mark bugs with any of the following 4 flags, to help categorise things:
- “low_hanging” for junior jobs.
- “Brainstorm” when you are unsure if this bug is really fixed, or is a particularly tricky bug.
- “MOVIT” for all GPU issues.
- “timeline_corruption” for all timeline issues.
Special Case: Feature Requests
Feature requests should have their severity set to "wishlist". Additionally, they should be marked as CONFIRMED as long as:
- It is conveyed clearly what the feature should do and how it would be useful.
- The feature has not already been implemented in a Kdenlive update since the report was written. Mark as RESOLVED FIXED in this case.
- The feature is within the scope of Kdenlive's goals. For example, don't accept requests like "Add 3D modeling support for Character animation".
Tips and Tricks
Get Notifications on New Bugs
Open a list of all UNCONFIRMED Kdenlive bugs, scroll down to the end of the list and click on 
to add a feed of new Kdenlive bugs to your atom feed reader.
Better Display for Buglists
Go to the Bugtracker: Bugtracker
Scroll down to the bottom and click on “Change Columns” -> add from the left window the item “Flags” and “Severity” to the right window
Click on “Change Columns” -> now you see the Flags which are set already -> click on “Flags” to get it sorted and you see all low_hanging bugs we found so far (I mean it could be a low hanging). The column “Sev” show you the “wis” for whislist and “cra” for crash as well.