add categories, redundant
add pt_BR link in translation header
|Deletions are marked like this.||Additions are marked like this.|
|Line 3:||Line 3:|
|||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[es/BTS/HowTo|español]]- [[it/BTS/HowTo|Italiano]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]||||||<tablestyle="width: 100%;" style="border: 0px hidden">~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: English - [[es/BTS/HowTo|español]] - [[it/BTS/HowTo|Italiano]] - [[pt_BR/BTS/HowTo|Português (Brasil)]]-~||<style="text-align: right;border: 0px hidden"> (!) [[/Discussion|Discussion]]|||
The BTS can keep track of the bug's versions. It's possible to state in which version a bug was found and in which version it was fixed.
Information on manipulating bugs by email
The complete documentation is found at: http://www.debian.org/Bugs/server-control
found, notfound, close
If you want to state that the bug 123456 is present in the version 1.2-3 of the package, you have to mail email@example.com with:
found 123456 1.2-3
---> The version might be older or newer than the one the bug has been reported for. It's just a way of stating that you know the bug is present in it.
If you want to say that the bug 123456 is not present in the version 1.2-3 of the package, you have to mail firstname.lastname@example.org with:
notfound 123456 1.2-3
If you want to say that the bug 123456 was fixed in the version 1.2-3 of the package, you have two ways of doing it.
You can send a mail to email@example.com, that starts with a pseudo-header containing the following fields:
Package: foo Version: 1.2-3
---> The Source-Version field is also available.
Or you can send a mail to firstname.lastname@example.org with:
close 123456 1.2-3
---> In this last case, it's probably a good idea to CC: email@example.com, so that the bug submitter knows that the bug was fixed in that version.
Branches and NMU
The new system reads the Changelogs of the packages, so if a bug is fixed in a branch that is not in the debian/changelog of the current sid version (for example, if it appeared in a security update for stable, or similar), you can just state that the bug is found in that version and the system will realize that this version is not applicable to the current version in sid.
Also, if a bug is fixed in a NMU but the version of the NMU that fixed it is not incorporated when the next upload happens, the bug will remain open until the changes of the NMU are incorporated.
Closing invalid bugs
If a bug that is not really a bug gets reported (this is to say, a user failing to understand how the program actually works, or similar), it can still be closed sending a mail to firstname.lastname@example.org without the pseudo-header, or using close 123456 without versioning.
If you need to reopen a bug that was closed as invalid, you would use the old reopen command. But if you are going to reopen a bug, because it's still present in the current version, you should send a mail to email@example.com:
found 123456 2.3-4
If in need of reassigning it would be a nice gesture to include the affected version of the package. In your mail to firstname.lastname@example.org do:
reassign 123456 bar 2.0-1
Distribution specific tags
The sarge tag now means "don't archive this bug until it has been fixed in a version in sarge".