Differences between revisions 1 and 38 (spanning 37 versions)
Revision 1 as of 2007-05-26 21:13:38
Size: 6712
Editor: SimonHuggins
Comment: First attempt at a bug triaging page
Revision 38 as of 2021-08-08 03:23:38
Size: 8735
Editor: PaulWise
Comment: minor link improvements
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
Most packages have bugs in Debian's [http://bugs.debian.org/ BTS] (Bug Tracking System). This page describes some ways that anyone can help maintainers to deal with them. Most packages have bugs in Debian's [[https://bugs.debian.org/|BTS]] (Bug Tracking System). This page describes some ways that anyone can help maintainers to deal with them.


<<TableOfContents(3)>>

= Other documentation =

 * BTS Introduction: '''[[HowtoUseBTS|How to use BTS]]'''
 * Talks about Bug Triage by Solveig: '''[[https://meetings-archive.debian.net/pub/debian-meetings/2014/mini-debconf-barcelona/Bug_triaging_and_bug_closing_by_Solveig.webm|MiniDebConf BCN 2014]]''' and '''[[https://debconf18.debconf.org/talks/31-learn-how-to-triage-bugs|DebConf18]]'''
 * First read this document on '''[[BugReport/WorkingOn|working on bug reports]]''' and how to find more informations.
 * There are many commands that the control interface to the BTS accepts and you might want to read the '''[[https://www.debian.org/Bugs/server-control|Guide to bug control on the BTS]]''' to find out more about them, so that you know what is possible when talking to `control@bugs.debian.org`
 * See also the '''[[https://www.debian.org/Bugs/Developer#closing|Guide to bug closing]]''' in case you plan to do so.
 * "[[https://www.chiark.greenend.org.uk/~cjwatson/blog/bug-triage-rants.html|Bug triage rants]]" blog post by Colin Watson.
Line 5: Line 17:
 * Read this document with a good pinch of common sense; use your own judgement in cases you're not sure about or ask someone who is more experienced. (apologies for being patronising but some of this stuff you just get a feel for)
 * You don't have to do everything this page says; do as much as you are comfortable with but don't be put off helping. Even small contributions can be valuable.
 * Look at the source package bug page on the BTS or look at all that maintainer's bugs in order to get a better overview and to spot duplicate bugs.
 * Mails to `<bugnumber>@bugs.debian.org` go to the relevant maintainer(s) automatically but not the submitters or others who may be interested. Be sure to include the bug submitter in the To: or Cc: if you want them to see it.
 * Most of the time, put <bugnumber>@bugs.debian.org in the Reply-To: so that people know where to follow up to.
 * Don't be afraid of `control@bugs.debian.org`; it's a public interface and anyone can help maintainers by helping them to triage bugs.
 * Do listen to maintainers if they notice you triaging bugs and email you separately giving you advice or guidelines.
 * Read the [http://www.debian.org/Bugs/server-control Guide to bug control on the BTS] so that you know what is possible when talking to `control@bugs.debian.org`

 * '''Help D
ebian out by triaging bugs!'''
 * Read this document with a good pinch of '''common sense'''
 * In cases you're not sure,
use your own judgement or '''ask someone who is more experienced''' (apologies for being patronising but some of this stuff you just get a feel for).
 * '''Even small contributions are valuable'''. You don't have to do everything this page says; do as much as you are comfortable with but don't be put off helping.
 * '''Don't be afraid''' of `control@bugs.debian.org`; it's a public interface and anyone can help maintainers by helping them to triage bugs.
 * '''Do listen to maintainers''' if they notice you triaging bugs and email you separately giving you advice or guidelines
.
 * Look at the source package bug page on the BTS or look at all that maintainer's bugs in order to get a better overview and '''to spot duplicate bugs'''.
 * Mails to `<bugnumber>@bugs.debian.org` go to the relevant maintainer(s) automatically but not the submitters or others who may be interested. Be sure to include the '''bug submitter in the To: or Cc:''' if you want them to see it.
 * Most of the time, put {{{<bugnumber>@bugs.debian.org}}} in the '''Reply-To''': so that people know where to follow up to.
 * Send the mail in '''text format''' and not html. (for icedove it's in Account settings > Composition & addressing)
 * '''~+Help
Debian out by triaging bugs!+~'''
Line 20: Line 32:
=== Confirming bug reproducibility ===
Line 23: Line 37:
{{{
found <bugnumber> <versionnumber>
tags <bugnumber> +confirmed

{{{#!wiki blue/solid
found <bugnumber> <versionnumber><<BR>>
tags <bugnumber> +confirmed<<BR>>
Line 29: Line 44:
=== 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 `<bugnumber>@bugs.debian.org` and the submitter (and anyone else who has the problem) for more information in order to try to reproduce it.

=== Closing unreproducible bugs ===
Line 30: Line 51:
{{{
{{{#!wiki blue/solid
Line 33: Line 55:
Line 34: Line 57:

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 `<bugnumber>@bugs.debian.org` and the submitter (and anyone else who has the problem) for more information in order to try to reproduce it.
Line 40: Line 61:
{{{
reassign <bugnumber> <correct package>

{{{#!wiki blue/solid
reassign <bugnumber> <correct package><<BR>>
Line 45: Line 67:
To find the correct package if you don't know you might use `dpkg -S <some file>` to find which package actually ships a particular file or use the interface to [http://www.debian.org/distrib/packages search the contents of packages] (at the bottom of that page). To find the correct package if you don't know you might use `dpkg -S <some file>` to find which package actually ships a particular file or use the interface to '''[[https://www.debian.org/distrib/packages|search the contents of packages]]''' (at the bottom of that page).
Line 52: Line 74:
{{{
merge <bugnumber for one of the bugs> <bugnumber for the other bug>
{{{#!wiki blue/solid
merge <bugnumber for one of the bugs> <bugnumber for the other bug><<BR>>
Line 57: Line 79:
== Forwarding reports upstream == == Working with upstream ==
Line 59: Line 81:
Many bugs in Debian packages are bugs in the upstream package which have affected Debian users. If the package has an upstream bug tracker (see the upstream webpage for reference) then searching it for similar reports can be useful and may yield either a work around or in some cases the fact that the upstream author doesn't consider it a bug or doesn't want to fix it.   Many bugs in Debian packages are bugs in the upstream package which have affected Debian users. If the package has an upstream bug tracker (see the upstream webpage for reference) then searching it for similar reports can be useful.
Line 61: Line 83:
=== Finding a similar report upstream ===

If it yields either a work around or in some cases the fact that the upstream author doesn't consider it a bug or doesn't want to fix it.
 
Line 62: Line 88:
{{{
forwarded <bugnumber> <URL of the bug in upstream's bugtracker>
{{{#!wiki blue/solid
forwarded <bugnumber> <URL of the bug in upstream's bugtracker><<BR>>
Line 67: Line 93:
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. You should also tell the BTS that you have done so with the `forwarded` command as above. === fixed-upstream ===
Line 71: Line 97:
=== patched ===
Line 73: Line 101:
== Other resources == === Forwarding reports upstream ===
Line 75: Line 103:
Often team maintained projects have an IRC channel and/or a mailing list for the team. You can use these as resources when you are triaging bugs. If they have an IRC channel you may well find other users around at the same time that you can enlist to try to reproduce a bug you're having trouble reproducing or other people to advise you on issues with bugs. 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.
Line 77: Line 105:
Upstream normally have a mailing list for their software even if they don't have a bug tracker and they may have an IRC channel too. Again an IRC channel might be useful to find people who can help you to reproduce or rule out bugs. You should also tell the BTS that you have done so with the `forwarded` command as above.
Line 79: Line 107:
Search engines can some times be useful resources in tracking down if other distributions or people have seen the same bug. == Closing bug reports ==
Line 81: Line 109:
== Other bug manipulation == ''Normally, the only people that should close a bug report are the submitter of the bug and the maintainer(s) of the package against which the bug is filed.''
Line 83: Line 111:
There are many commands that the control interface to the BTS accepts and you might want to read the [http://www.debian.org/Bugs/server-control Guide to bug control on the BTS] mentioned earlier to find out more about them. The best is to write a patch and wait for the maintainer to close the bug once the package is updated with your patch.

You can also close bug reports if a new version fixed the problem, but remember to [[https://www.debian.org/Bugs/server-control#fixed|say in which version]] it was fixed.

You can close bug reports that are tagged "moreinfo" since more than a year, if no info has been provided and it seems unreproducible.

= Help is welcome =

== Teams that welcome help ==

If you want to triage bugs, it can be easier to do so inside a team - so you're sure there are many packages with many bugs to triage, and helpful people to answer questions. Teams that welcome bug triaging:

 * [[https://qt-kde-team.pages.debian.net/|Debian Qt/KDE Maintainers]],
 * [[Games/Team|games]],
 * [[Haskell]],
 * [[Teams/OTR|OTR]],
 * [[Teams/DebianPerlGroup|perl]],
 * [[Teams/XStrikeForce|X Strike Force]],
 * If you understand anything, I know the kernel also needs bug triaging.

== People that welcome help ==

These people, while not having so many packages as a team, do also welcome bug triaging:

 * [[https://qa.debian.org/developer.php?login=bignose|Ben Finney]]
 * [[https://qa.debian.org/developer.php?login=gregoa|gregoa]]
 * [[https://qa.debian.org/developer.php?login=mones|Ricardo Mones]]
Line 90: Line 144:

----
CategoryBugs | CategoryRedundant: merge with [[BTS]]

Most packages have bugs in Debian's BTS (Bug Tracking System). This page describes some ways that anyone can help maintainers to deal with them.

Other documentation

General points

  • Read this document with a good pinch of common sense

  • In cases you're not sure, use your own judgement or ask someone who is more experienced (apologies for being patronising but some of this stuff you just get a feel for).

  • Even small contributions are valuable. You don't have to do everything this page says; do as much as you are comfortable with but don't be put off helping.

  • Don't be afraid of control@bugs.debian.org; it's a public interface and anyone can help maintainers by helping them to triage bugs.

  • Do listen to maintainers if they notice you triaging bugs and email you separately giving you advice or guidelines.

  • Look at the source package bug page on the BTS or look at all that maintainer's bugs in order to get a better overview and to spot duplicate bugs.

  • Mails to <bugnumber>@bugs.debian.org go to the relevant maintainer(s) automatically but not the submitters or others who may be interested. Be sure to include the bug submitter in the To: or Cc: if you want them to see it.

  • Most of the time, put <bugnumber>@bugs.debian.org in the Reply-To: so that people know where to follow up to.

  • Send the mail in text format and not html. (for icedove it's in Account settings > Composition & addressing)

  • Help Debian out by triaging bugs!

Ways you can help

Trying to reproduce bugs

Confirming bug reproducibility

Try reproducing old bug reports or any recent bug report which isn't tagged confirmed or pending.

If you can reproduce the problem then you should send a message to <bugnumber>@bugs.debian.org saying so and a message 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 <bugnumber>@bugs.debian.org and the submitter (and anyone else who has the problem) for more information in order to try to reproduce it.

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 by mailing <bugnumber>-done@bugs.debian.org with an explanation of why this bug is now fixed (or how you couldn't reproduce it in the current version though be careful as you may just have a different setup to the submitter). Add as the first line of that message:

Version: <current version of the package you tested it under>

so the BTS knows which version it was fixed in and add a blank line under that before your message.

Reassigning bugs

If a bug is filed against a generic or meta-package but actually concerns a different package then please reassign it to the correct package with a message to control@bugs.debian.org which says:

reassign <bugnumber> <correct package>
thanks

To find the correct package if you don't know you might use dpkg -S <some file> to find which package actually ships a particular file or use the interface to search the contents of packages (at the bottom of that page).

You might find when it is reassigned to the correct package that there is another bug for the same issue in which case please merge them (see below).

Merging bugs

If you find two bugs for the same issue then they should be merged together. To be merged bugs must be on the same package and with the same severity and state. You can manipulate the packages, severity and tags with a message to control@bugs.debian.org and at the end to merge the bugs add:

merge <bugnumber for one of the bugs> <bugnumber for the other bug>
thanks

Working with upstream

Many bugs in Debian packages are bugs in the upstream package which have affected Debian users. If the package has an upstream bug tracker (see the upstream webpage for reference) then searching it for similar reports can be useful.

Finding a similar report upstream

If it yields either a work around or in some cases the fact that the upstream author doesn't consider it a bug or doesn't want to fix it.

Both of these are useful information so post to the bug <bugnumber>@bugs.debian.org cc'ing the submitter and let them know. You might like to tell the BTS that the bug exists in upstream's bugtracker by sending the following to control@bugs.debian.org:

forwarded <bugnumber> <URL of the bug in upstream's bugtracker>
thanks

fixed-upstream

If you find a report that upstream claim 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.

patched

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 does indeed fix the bug then you could include it in the mail and tag the bug patch.

Forwarding reports 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.

You should also tell the BTS that you have done so with the forwarded command as above.

Closing bug reports

Normally, the only people that should close a bug report are the submitter of the bug and the maintainer(s) of the package against which the bug is filed.

The best is to write a patch and wait for the maintainer to close the bug once the package is updated with your patch.

You can also close bug reports if a new version fixed the problem, but remember to say in which version it was fixed.

You can close bug reports that are tagged "moreinfo" since more than a year, if no info has been provided and it seems unreproducible.

Help is welcome

Teams that welcome help

If you want to triage bugs, it can be easier to do so inside a team - so you're sure there are many packages with many bugs to triage, and helpful people to answer questions. Teams that welcome bug triaging:

People that welcome help

These people, while not having so many packages as a team, do also welcome bug triaging:

Thanks

If you have triaged bugs in anyway whatsoever then thank you for your contribution to Debian.

Don't stop there though! There are always more bugs and maintainers are always grateful for all the help you can give them.


CategoryBugs | CategoryRedundant: merge with BTS