email: debian[at] ; irc: Solveig on

Bug triaging: it helps Debian as a whole! -> search for a bug by number

Bug triaging: you want to do it

Bug triaging: different operations

Detailed information on and (

Reproducing bug reports

Tagging unreproducible bugs

If you can't reproduce it but you're not sure it's fixed you could tag the bug as unreproducible and/or moreinfo and mail

tags bugnumber +unreproductible +moreinfo  

Merging bugs

Two bugs for the same issue? They should be merged together. Both bugs must be on the same package and with the same severity and state. Fix that, and at the end to merge the bugs add:

merge bugnumber-first-bug bugnumber-second-bug  

Forwarding reports upstream

Dealing with upstream

Dealing with submitters

Find bugs to close

Don't close random bugs! You can find packages that have a lot of bug reports, and ask the maintainer if help is welcome, or even better: find welcoming teams, so you're sure there are many packages with many bugs to triage, and helpful people to answer questions. Teams that were welcoming to me so far: perl, games, X Strike Force. If you understand anything, I know the kernel also needs bug triaging.

Searching for bugs to triage? Searching for bug triagers to help with your bugs?

UDD searches with specific criteria

UDD (Ultimate Debian Database) Bugs search allows you to select bug reports according to many criteria. A good way to get started with bug triaging (and closing!) is to start with those that are lost and forgotten: * let's ignore those that have been created or modified in the last year. * select wontfix, moreinfo, upstream or unreproducible * choose a team (you can make your own requests with other teams, and add them to the interface if you want) * start reading and trying to figure out :)

Closing unreproducible bugs

If you are sure that the bug does not exist in the current version of the package then you should close the bug report by mailing Add as the first line of that message:

Version: <current version of the package you tested>

so the BTS knows in which version it was fixed. (

Closing moreinfo/wontfix bugs


In case of doubt...

Not sure? Let it rest a while. You can come back to it in a few days/weeks/months, no hurry - maybe another time you'll see more clearly what the next step is. You can also ask the maintainer for their opinion... if you agreed to work together on that. Some maintainers don't have time to triage and also not to teach triaging, so not all of them are going to take the time.

Say what you're doing

Document your changes! When doing something, say what & why, make sure everybody is in the information loop (did other people report having the same bug? did the upstream give input?), and give as much information as possible in the email: no need to write a novel, but enough info should be provided for the others to see what you're doing, and why, without re-reading the whole thread. You can have a few generic messages for each situation, that you copy/paste. Bonus points for remembering to be nice in the messages :)


Never close a bug report made by Ian Jackson, unless you know how to deal with berserkers.

Beware, there are certainly others out there.

...but keep on!

I assure you, there are also a lot of very nice Debian contributors with whom it's a pleasure to cooperate and discuss.

And remember: bug triaging is fun. And rewarding. And easy (once you've started).