This is the third post in my blog series: bugs.kde.org for developers.
Today’s blog post in my series on bko for developers is about searching in bugzilla. Now you will say searching is easy I know all about it: trust me if you are not a developer of Amarok/Phonon, Plasma, KWin, Solid or Telepathy you will learn new things. Yes bko can even tell me if you know how to search 😉
Searching by bug number
On each page of Bugzilla you have access to the quick or simple search through a very prominent field. This is a great search field for users, but mostly useless for developers: you don’t want to use it. A more detailed explanation can be found in the help on Quicksearch.
Quicksearch is a wonderful tool if you already know the bug number or alias you want to go to. But if you already know the bug number you don’t need to use Quicksearch, but you can use a web shortcut in combination with KRunner:
The web shortcut “bug:” allows to search in bko with search term either bug id or alias independent of used browser. If you don’t know about alias: you can give each bug a human readable name – the alias. That is particular useful if you have a bug report which has many duplicates like the one in the screenshot. To set an alias you need to edit the bug summary which reveals a field to enter the summary. Use the alias wisely: you need to remember it and remember that bko is a global database, so better use a prefix.
The Advanced Search
The real search for developers is the Advanced Search. It has an entry in the global navigation, but I recommend you not to use it, but to set a bookmark on a slightly adjusted link with “&product=
Now what is important to know about the Advanced Search is that it is not about searching like e.g. Google. Of course you can also use it to search in bko, but it’s much more powerful. It is the key to turn bko into a tool to support your workflow. In my last post I wrote that I use emails to get all information about bugs for kwin. This is only partially true, I start to transit to using only searches.
Why is the search so powerful? It allows you to search on any information you put into the bug. You want to have all bugs in a specific component reported between beta tagging and beta release? No problem with advanced searches. You want to see all bug reports with a specific target milestone and having a patch as attachment? No problem with advanced searches.
I use the searches for example to see all bugs which have changed for KWin in the last 24 hours. That is very similar to what I also have in my mail inbox. But it’s better: it gives me the context on how I need the bug. What’s the status of the bug? When has it been changed before? Is it scheduled? Confirmed? Triaged? All these information I have in one table, but are missing in the mails. It allows me to better schedule when I want to work with the bugs.
Other searches I use are for bugs with a specific target milestone. It is so to say my personal TODO list. It needs more work, but it can be tuned into telling me what I have to work on today.
So it is a very powerful tool and the UI is very complex, that’s why I cannot introduce all the specific features in this post. I can only suggest to start reading the documentation and experiment with the search capabilities.
Saved Searches
As mentioned the searches are very powerful and that means it takes quite some time to get the query in the way you want to have it. And if you use the same query again and again (e.g. all bugs changed in the last 24h) you don’t want to spend five minutes on setting up the query each time.
Of course bko has something for you: saved searches. Whenever you perform a search, underneath the search result there is an input field to name and remember the search:
As you can see the saved searches are shown in the footer of each page and you can always get to a search by just one click.
Defining searches and saving them is already a quite important feature to efficiently work with bko. But you normally work in a team and you can expect that your team mates have to search for the same things as you do, right? It would be a pity if everybody has to setup the searches. Of course bko has a solution for this problem. Go to Preferences -> Saved Searches. Here you can edit and manage all your searches but even more important you can share your search with groups.
If a search is shared it is listed on this page and you can just add it to your searches shown in the footer. So all the searches defined by your team members can be made available for the complete team. As shown in the introduction only very few teams make use of this feature, in fact it looks like half of all saved searches are for Amarok/Phonon. And Amarok is one of the products which got the bug count quite low over the last few years. So learning from the great work done there will help you.
Going Through Search Results
When working with the searches it’s of course important to see the information you really need. Therefore the search layout can be customized using “Change Columns”. This allows you to add/remove and reorder the columns listed in the search. Of course you can save the layout for each of your searches or just change the layout for your current session.
If you use the searches to go through a list of bugs, it can be very useful to not use the default tabular layout but to switch to the “Long Format”. This shows all bugs in the search result aggregated. That is you have all the comments and all bug fields. A quite useful feature also when searching for a duplicate. Unfortunately this view cannot be used to edit bugs, for that you still have to properly open the bug.
Bko also keeps the context when you open a bug from a search result. That is on each bug page you have pagination to navigate through the search result. If you change a bug by default bko will also open the next bug from your bug list, but you can change this behavior in the preferences.