What I’m about to write is grounded in darktable environment but might be easily adapted to any free software.
We just published darktable 3.0rc1. That’s the second release candidate of the soft before the stable release planned for Christmas. This one changes a lot of things, improves a lot of things, but breaks some things too, and we are still trying to fix them.
The release candidates are different from development snapshots since the former have to be compiled manually and target mostly tech-savy people, but the latter are provided as pre-built packages anyone can install. [EDIT: @darix pointed that dev snapshots are also pre-built — but far less advertised than RC] Obviously, when an RC is published, a lot more bugs reports come in compared to the usual (which is the point). In addition, we (I) have built up people expectations about new features, so it’s all the more disappointing when things don’t work out of the box.
So, you go report your bugs, and you are right.
But…
We are the developers. That means we can guarantee you that the software works on our computers. Just as much as you can garantee us that is doesn’t on yours. That doesn’t help, does it ? When fuzzy, incomplete bug reports are posted, imagine you gave us a closed black box saying “the thing inside doesn’t work”. What doesn’t work how and what did you expect ?
There are 3 kinds of bugs:
- the ones we can reproduce, usually the nicest,
- the ones we can’t, where the nightmare begins,
- the ones that are working features misunderstood or misused by users, where RTFM is usually enough.
Bug fixing is an experimental and scientific process in which you try to understand what behaves the same and what behaves differently between a working environment (ours) and a faulty one (yours), or between a working use case and a faulty one, to get an intuition about the causes of the misbehaviour. Bug fixing is something you do, most of the time, without direct access to the faulty system, so we rely solely on the info you give us and what we know of your system. As of today, there are more than 300.000 lines of code in darktable only for the core, that means at least 300.000 possible origins of bugs. And, make no mistake, not a single developer knows every one of these 300.000 bad guys.
Since we usually don’t have access to the failing machines, all we can do is trying to find patterns of reproduction to get a smell of the origin of your bug and narrow down the possible origins of the bug in the code. Then, it’s a silly game of trial and error until we have found the causes. Finally, we still need to fix it without breaking something else, which is never guaranteed.
Usually, these bugs are caused by different GPU drivers (AMD and Intel OpenCL have given us much pleasure lately, they don’t behave at all like Nvidia ones), or different OS (GTK differentied support on Windows and Mac, while trying to come clean on the style and themes, has been a true pleasure too), or different versions of the libraries (supporting GTK 3.18 to 3.24 is nice as well, given their sane habit of deprecating half their API every 2 years).
We are not a big team here. Github lists almost 300 contributors, but the day-to-day cleanup is done essentially by a handful of people, most of them on evenings and weekends aside from their day job, most of them running Linux (with limited debugging possibilities on Win and Mac). As the release is approaching, fatigue increases and it’s not going to cease until December 25th.
So, please, help us help you.
-
When you report a bug, don’t just dump a backtrace (even if they help), detail what system you use (OS, RAM, CPU, GPU, desktop flavour) but also whether you use OpenCL or not and the version of your driver and of the supported OpenCL set.
-
If your bug is related to colour, detail what colour profiles you use along your pixel pipeline (working, histogram, display, input) and reset your desktop colour profile to default or sRGB, to see if it helps.
-
Backup and reset your
~/.config/darktable
directory too, and see if that helps. If your problem is with some module, try to move it in the pipe and see if that helps. -
Try to send us your raw files + XMP editing histories so we can see exactly what you did to produce the bug.
-
Explain what you did when things went bad. The actions done prior to the bug are just as useful as the backtrace showing the line of code that failed.
Once you do that, we will get much more information to get started, identify if it’s possibly related to some other bug report, and we will lose less time asking you to provide more details about your config or how you understood the soft was supposed to behave. It feels nicer too.
Thanks and have a happy holiday season !