Using rng for bug triaging
Reportbug-NG’s ability to filter and sort bugreports in various ways can greatly help triaging bugreports after a certain criterion.
In this example I use the bugs of the KDE team, because they have quite a lot of bugs and are currently on a bug triage.
Two releases ago I tried to help them cleaning their BTS from obsolete bugeports. My tactic back then was to find bugreports where no action has been taken for a long time. I noticed that there was no easy way to find such bugs since neither reportbug nor the BTS allowed to sort the bugs this way, so finding the candidates I searched for was very cumbersome.
So let’s try to find those bugs with rng: To get all bugs belonging to the KDE team start rng with the maintainer as argument:
After rng started you see a table with all bugreports against the packages of the KDE team. To find potentially solved or unreproducible bugs, click on the last column header to sort the list by the date of the last action. The date of the last action is the date where the bugreport received it’s last mail (including firstname.lastname@example.org mails). You will see that there are quite a lot bugs which haven’t been touched for more than two years. Many of them don’t have a unreproducible or moreinfo tag. If you want to help the KDE team, you can now start trying to reproduce the bug. If that’s not possible you can tag them with moreinfo and unreproducible. If there is no reply in roughly one month or so it’s probably safe to close this bug.
To quickly find a lot of other candidates to close one can use the filter of rng. Just enter moreinfo in the filter and the table will reduce to all bugreports containing this word or tag. Now you can again sort this list by date of last action and you will see quite a lot bugs bugs where more info was requested but no action took place for more than one year. Those need to be inspected, but probably quite a few of them are safe to close.
This example shows how filtering and sorting can greatly help to find certain bugs and support bug triaging. But please: don’t carelessly close very old bugs! Read the reports and try to reproduce them, find matching bugreports in upstream’s BTS and ask the submitter if in doubt.