The bugs are on Launchpad :

Launchpad has different status for bugs. We use the following meaning :


New : the bug has not been accepted or clarified enough. Maybe you just have to wait. If you want that specific bug to be confirmed, you might help by adding a precise way to reproduce the bug or, if it's a feature request, by clarifying the feature (mockups, usecases). If this is a feature request which is not clear, we usually set the Importance to Wishlist and leave the status to New.

Incomplete : the bug is not understood or not reproducible by Xpad developers. Please answer in the comments.

Invalid : bug not related to Xpad

Won't fix : self explanatory

Confirmed : the bug has been accepted as a bug we want to see fixed. It doesn't mean that we plan to work on it soon. See the importance field for that. It also doesn't mean that we agreed on a solution (even if the original bug describes a particular solution). It only means that we acknowledge that there is a problem that need to be adressed. If you work on one of those bug in your branch, you have no guarantee that it will be accepted.

Triaged : the bug has been accepted and a particular solution reached the consensus. This solution should be described in the main summary of the bug. Solving a Triaged bug is just a matter of coding according to the bug description. No further reading nor discussion should be needed. If the proposed solution implies a modification of the core UI (not plugin), it should have been approved by Bertrand, our UI manager.

In progress : someone is actively working on that bug (see the assigned to field). Also use this status if the bug is fixed in your branch and then do a merge request a link the branch to that bug.

Fix Committed : The bug has been fixed in the trunk (not in your branch). When changing to this status, always add the revision number that fixes that particular bug. You also have to be sure that the bug is targeted for the next release. Indeed, if the fix is in the trunk, it will be in the next release. Don't forget to do that! Also, every Fix Committed bug should be assigned to someone. If multiple people have worked to fix a bug, use the last one that will commit the fix.

Fix Released : On a given release, all the Fix Committed bugs are switched to that state.


Unlike the Status field, the Importance field is more up to your appreciation.

Critical : Xpad cannot be released without solving this bug. This include crashes or very odd behaviour. As we are closer to the release, more bugs become criticals.

High : Bug that might be critical for some users (like localization) or that give a bad user experience. Also use that for

medium : OK, we want to fix that bug it might not make it in the next release. We will try.

Low : we'd like to have that.

Wishlist : this is clearly a feature request (such as an idea for a plugin) and this feature is clearly not critical for Xpad. If it's not assigned to someone, it might not happen until someone take an initiative.

Assigned to

If you assign a bug to yourself, it means that you plan to work on that bug in the near future or that you already have a branch. When you are currently working on a bug, mark it as In Progress.

If you want to work on a bug assigned to somebody else, assign it first to you. If the bug is marked as "In Progress", be sure to contact the person working on it before to avoid duplicate work.

Assign the bug to someone else only if it makes a lot of sense. For example, a bug in a plugin should be assigned to the plugin author.

If a bug is assigned to you, be sure to reply as quickly as possible. If you cannot fix the bug or you don't plan to work on Xpad for some time, please communicate it as soon as possible (use the comments of the bug).


Milestone can change. Be assured that each Fix Committed bug is targeted at the nearest milestone.

Apps/Xpad/bugstriaging (last edited 2015-01-06 10:35:11 by OliverPropst)