Me

email: debian[at]solveig.org ; irc: Solveig on irc.debian.org

• Free software enthusiast and Debian user for ten years, teaching Linux newcomers about privacy issues and solutions.
• Longtime Tails (Debian derivative) contributor for documentation, translation, user support, and helps core developers with design decisions. Also: new contributors recruiting, please talk to me :)
• Debian bugs triager since last DebConf

Bug triaging: it helps Debian as a whole!

https://www.debian.org/Bugs/ -> search for a bug by number

• Maintainers don't always have the time to deal with all bug reports (some high popularity packages get a lot of them. And sometimes, maintainers just don't have much time).
• It's a great way to improve package quality: up-to-date bug reports are more useful, and maintainers have then more time to fix those that can be fixed!

Bug triaging: you want to do it

• easy: only read & write emails needed
• rewarding: maintainers are happy you helped :)
• fun: you get to read and learn many things about many different packages, some of them you would not have guessed somebody would code it
• of course, it also saves kittens.

Bug triaging: different operations

Detailed information on https://wiki.debian.org/BugTriage and
https://www.debian.org/Bugs/server-control (control@bugs.debian.org).

• Reproducing bug reports
• Tagging unreproducible bugs
• Merging bugs
• Forwarding reports upstream
• Dealing with upstream
• Dealing with submitters
• And, best of all: closing

Reproducing bug reports

• Bug reports from older versions: do they still apply?
• New bug reports: can you confirm them?

• If yes, write it to nnn@bugs.debian.org, and tag them by sending an email to control@bugs.debian.org which says:

    found bugnumber versionnumber  
    tags bugnumber +confirmed  
    thanks

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 nnn@bugs.debian.org:

tags bugnumber +unreproductible +moreinfo  
thanks

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  
thanks

Forwarding reports upstream

• Many bugs in Debian packages are bugs in the upstream package. Search the upstream bug tracker for similar reports, to find either a work around or in some cases the fact that the upstream author won't fix it, and post the information to the bug nnn@bugs.debian.org
• Tell the BTS that the bug exists in upstream's bugtracker by sending the following to control@bugs.debian.org:
  forwarded bugnumber URL-in-upstream's-bugtracker
  thanks

Dealing with upstream

• If you can't find a report upstream but it looks like a bug in upstream's software and you can reproduce it then you should file the bug in the upstream bugtracker with all the information necessary to reproduce it. Tell the BTS that you have done so with the forwarded command as before.
• If you find a report that upstream claims it's fixed you could tag the bug fixed-upstream but be sure to mail the bug and explain why and which version it's fixed in which may persuade the maintainer to upload the new version.
• If you find a bug in upstream's bugtracker has a patch then reviewing and/or testing it and mailing the bug to give the results is useful. If you find a patch that works, then you could include it in the mail and tag the bug patch.

Dealing with submitters

• In lots of cases, the bug is tagged moreinfo and the submitter doesn't provide any; or a new version has been out, and you're not sure the submitter still experiments the bug; or they said they would make more tests, or report to upstream, or... and nothing happened. Since a long time (a year, or a release).

• You can help: send an email to the person whose input is needed (and nnn@bugs.debian.org) saying "Hey, you said you would test" or "can you still reproduce the bug?" can help clarifying the status of the bug.

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? https://wiki.debian.org/BugTriage#Teams_that_welcome_help

UDD searches with specific criteria

https://udd.debian.org/bugs.cgi

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 nnn-done@bugs.debian.org. 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.

https://www.debian.org/Bugs/Developer#closing (nnn-done@bugs.debian.org)

Closing moreinfo/wontfix bugs

• Make sure with the team/maintainer beforehand what is their policy regarding moreinfo and/or wontfix bugs. Some like to keep all of them open indefinitly. Some wontfix bugs should stay open to avoid new bug reports about the same issue. But lots of them can be closed after a while (I arbitrary decided one year after the submitter was pinged and didn't answer, it could probably be shorter but I don't like angry submitters).
• Sure it's no use to anyone? Then you can close the bug by mailing nnn-done@bugs.debian.org with an explanation of why you're closing the bug.

Example

• Search: tagged wontfix, exclude created/touched in the last year, Perl team https://udd.debian.org/bugs/?release=na&wontfix=only&merged=ign&fnewer=ign&fnewerval=400&flastmod=ign&f>lastmodval=400&perl=1&sortby=last_modified&sorto=asc&format=html#results
• Read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511372

• Close! With nice email and providing necessary information:

  To: 511372-done@bugs.debian.org
  Subject: Re: libsoap-lite-perl: high memory usage under some circumstances - closing
  Hi! I'm closing this bug, since it was tagged "unreproducible" for some years, without answer. If you have new reasons to point out this problem, please feel free to re-open it or ask me to do it. Cheers,

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 :)

Warning

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).