Differences between revisions 4 and 18 (spanning 14 versions)
Revision 4 as of 2009-04-02 00:29:00
Size: 3223
Editor: BenFinney
Comment: one pseudo-header per message, which contains multiple fields
Revision 18 as of 2022-01-13 14:15:15
Size: 3718
Editor: ThiagoPezzo
Comment: make translation header easy to include in translations
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||<tableclass="sidebar" tablestyle="float:right; background: #eeeeee; margin: 0 0 1em 1em;" style="padding: 0.5em;"> [[Include(English/SideBar)]] ||
The BTS has changed quite a lot due to the new feature of keeping track of the bug's versions. It's now possible to state in which version a bug was found and in which version it was fixed.
## page was renamed from English/NewBTSHowTo
#language en
##For Translators - to have a constantly up to date translation header in you page, you can just add a line like the following (with the comment's character at the start of the line removed)
##<<Include(BTS/HowTo, ,from="^##TAG:TRANSLATION-HEADER-START",to="^##TAG:TRANSLATION-HEADER-END")>>
##TAG:TRANSLATION-HEADER-START
~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: [[BTS/HowTo|English]] - [[es/BTS/HowTo|español]] - [[it/BTS/HowTo|Italiano]] - [[pt_BR/BTS/HowTo|Português (Brasil)]]-~
##TAG:TRANSLATION-HEADER-END
----
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.
Line 4: Line 11:
The complete BTS documentation is found at:
http://www.debian.org/Bugs/server-control.en.html
== Information on manipulating bugs by email ==
The complete documentation is found at: http://www.debian.org/Bugs/server-control
Line 10: Line 17:
{{{
  found 123456 1.2-3
 {{{
found 123456 1.2-3
Line 14: Line 21:
-->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.  ---> 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.
Line 17: Line 24:
{{{
  notfound 123456 1.2-3
 {{{
notfound 123456 1.2-3
Line 21: Line 28:
 * 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.    * 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.
Line 23: Line 30:
{{{
        Package: foo 
        Version: 1.2-3
  {{{
Package: foo
Version: 1.2-3
Line 27: Line 34:
---> The `Source-Version` field is also available.   ---> The `Source-Version` field is also available.
Line 29: Line 36:
{{{
        close 123456 1.2-3
  {{{
close 123456 1.2-3
Line 32: Line 39:
--->In this last case, it's probably is a good idea to CC: `123456-submitter@bugs.debian.org`, so that the bug submitter knows that the bug was fixed in that version).   ---> In this last case, it's probably a good idea to CC: `123456-submitter@bugs.debian.org`, so that the bug submitter knows that the bug was fixed in that version.
Line 36: Line 43:
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. The new system reads the [[DebianChangelog|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.
Line 38: Line 45:
Also, if a bug is fixed in an 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. 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.
Line 48: Line 55:
  found 123456 2.3-4 found 123456 2.3-4
Line 55: Line 62:
  reassign 123456 bar 2.0-1 reassign 123456 bar 2.0-1
Line 62: Line 69:


----

CategoryBugs | CategoryRedundant: merge with [[BTS]]

Translation(s): English - español - Italiano - Português (Brasil)


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 control@bugs.debian.org 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 control@bugs.debian.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 123456-done@bugs.debian.org, 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 control@bugs.debian.org with:

      close 123456 1.2-3

      ---> In this last case, it's probably a good idea to CC: 123456-submitter@bugs.debian.org, 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 123456-done@bugs.debian.org without the pseudo-header, or using close 123456 without versioning.

Reopening

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

found 123456 2.3-4

Reassigning

If in need of reassigning it would be a nice gesture to include the affected version of the package. In your mail to control@bugs.debian.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".


CategoryBugs | CategoryRedundant: merge with BTS