BKO: Bug dependencies

This is the sixth blog post in my series bugs.kde.org for developers.

During software development it is quite normal that you have some dependencies between the bugs and features you want to implement. E.g. for feature foo you first have to implement feature bar. Bugzilla can help you track such dependencies in a nice way.

In most KDE projects I have seen poor man solutions to manage these problems. The most obvious one is to just write in one of the comments that first the other bug report needs to be implemented. But that’s a very bad solution. It can only be processed by humans by reading the comments and from bug report bar the reference is missing completely.

Another solution is to set bug foo to resolved later indicating that at some later state the bug will be fixed. But how likely is it that you remember to reopen that bug after you have implemented foo? I think it’s rather unlikely given the amount of bugs reported on bko that anyone is considering the resolved later bugs. I just checked that for KWin and of the 17 bugs resolved later many are fixed right now.

Another solution I have seen is to create a meta bug and set all depending bugs as duplicates of this one. We then find comments like “note: please check duplicates”. This is also a very bad solution as it requires to read through all the bug reports and it’s not what duplicates are for. It’s not the same issue after all.

All these solutions have one clear drawback: they cannot manage dependencies hierarchies. Consider the following hypothetical feature request: a user wants to be able to interact with a rotated window. This requires first generic support for rotated windows and support for input redirection. Input redirection makes only sense with Wayland. For this we need to add at least a build dependency in CMake, implement Wayland server and get rid of X. If we would want to we could split this up even further and we have a nice dependency tree like this one:

This is a graph rendered by bugzilla. So how does it work? It’s quite simple. Each bug report has two fields to manipulate the bug dependency: “Depends On” and “Blocks”. A bug which depends on another one can only be set to fixed after the other one is fixed. The same way a bug which is blocked cannot be fixed as long as the bug which is blocking is not fixed. In fact these two are exactly the same: if you add a depends on, the other bugs blocks field will be updated. So you can always navigate the tree from both sides.

Using the bug dependencies can really help you if you split up your work into multiple tasks. Combined with the searches you can get bugzilla telling you which bug you have to work on.