BKO: Components

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

Yesterday we looked at how to search in bko if there is useful information in it. Today we start adding the useful information: components. Now again I assume you will say that you know everything about components, but I have assigned bugs to so many products with too few components, that I decided components deserve an own post in this series.

Components can be used to group your bugs. You can use any grouping which might make sense to you. You could add components for the parts exposed to the user interface, components for implemented concepts (e.g. a protocol) or components for specific parts of the code base. My recommendation is to remember that the bugtracker is there to help you and that means you should use what makes sense to you and not what might make sense to users. Please don’t expect that users or triagers will find the right component – setting the component is something the developers have to do.

One of the advantages of components in my opinion that it makes bko less scary. You might have hundreds of bug reports which is difficult to manage and to go through. But when they are nicely separated in components everything is less scary. Your components might just have something between 10 and 20 bugs and that makes everything look much better. Just have a look at the component report of KWin.

The component report for your product is something you should bookmark. It is a very useful tool when searching for duplicates. You know the new reported bug has a duplicate: just go through the few bugs reported to the component. Much faster than using a search query.

If your bugs are nicely triaged into components it becomes much easier to work with the bugs. You can easily see which bugs exists for a specific code area, you immediately find the duplicates and similar bugs and you can nicely plan how to fix those bugs. There are very handy features to help you do the bug fixing planning – but that in a later post. Also you easily spot areas which requires work: if all your crash reports are in one component it might be a good idea to increase the priority of fixing bugs in that component.

In case you have developers in your team responsible for a specific part, you can set the developer as the default assignee and your general team bug account as the default CC list.

What we have not yet discussed is how to create components. There are two possible ways: create a sysadmin request to get the components for your product (sysadmin will need name, description, assignee and cc list) or in case you are a maintainer you could request to get higher privileges to create the components yourself. I highly recommend the latter as that makes your work with bko much more flexible. While doing a triaging session lately I realized that we need two additional components and I could just create them and send the bugs there without waiting for sysadmins to act and they really have enough work to do 🙂

You don’t have to be afraid of components becoming obsolete in future versions of your software: components can be deleted (if there are no bugs assigned to it) and can just be disabled, so that no new bugs can be assigned to that component.