darktable's Bug Workflow

darktable's issues are reported and managed in our own Redmine installation. In order to comment on bugs, update their status, and assign themselves to work on a given bug you have to register and create a user account. darktable Bug Team members can set the bug status to Triaged (more below) and assign priorities.

General notes

The different trackers

Currently we have two trackers, their intended usage is described below:

Bug status

We have the following bug statuses:

Bug importance

Importance reflects how serious is the bug.

Categories

Categories relate bugs to a subsystem or general area of functionality of darktable. Currently the following Categories are being used:

Target versions

darktable is a spare time project. So the development pace relies heavily on the given spare time of the developers. Therefore it does not make sense (and fun) to set up sophisticated roadmaps with due dates and all. Since we want to deliver bug fixes in patch releases as soon as possible we started to deliver them roughly one per month.

This has some implications on the "target version" of a bug or feature:

And then we have the numbered target versions. As said above: there is no absolute roadmap, especially not for patch releases. These targets are meant for regressions from a earlier version. So if the current stable version is "1.0.3", the target version "1.0.4" contains /just/ the regressions from the stable version - not all bugs in the version since it's very unlikely to have them fixed all at once. And after releasing "1.0.4" within a reasonable time we would have to move all unfixed bugs again to the next patch target version.

Redmine git integration

There are several things that make life easier. If you're working on a bug an you know the issue number you can close the ticket or just reference to the commit you're about to apply. This works as described here:

If you already made a commit and can't change the commit message accordingly or you found an issue that got solved by someone else you can still create a reference or at least a link to the commit. This makes it easier to find relates problems later.

Advices

The general methodology for working with bugs is as follows:

Be polite. It takes some effort on the part of the user to come to our site, navigate to the bug report section, and write up a report. If they know their report will be treated seriously and professionally, they'll respect the system and put in extra time to help us solve the issue.

Do not close an unreproducible bug unless a reasonable amount of effort is put into reproducing it, and let it rot for some time before closing -- someone may come up with a better report in comments. (In a few situations we might not be able to recreate the bug, but due to the involved assistance of the user might be able to narrow down and fix the problem, and the user is able to do the validation.)

Clarify. If it took you some time to guess what it's about, change the summary or add a comment, to make it obvious to whoever will be reading the tracker after you (especially if it's the person who can fix it). For example "problem with export" should be replaced with "artefacts when exporting NEF files with a small rotation enabled".

When closing a bug as Fixed, add a comment that includes the revision number of the first version without the bug. Linking to revisions is done with "commit:hash", where the hash should by the one of the commit containing the bugfix.

Always search for similar or duplicate requests before filing new reports.
When choosing which report should be marked a duplicate and which one left valid, older reports should be given priority over newer reports. Exceptions can be made if the newer report has significantly better information provided. Where appropriate, copy and paste across any relevant extra information as a comment to the bug report being left open.

Please do not randomly assign bugs or features to a developer or to the whole team ("Assignee: developers"). People will assign themselves if they want to work on a bug. If you know somebody that could contribute to a discussion or maybe knows a solution, add him/her to the watchers list rather than assigning the bug. He/she will be notified then.