[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

a few tips on proper use of version tracking in the Debian BTS

In the process of my work on the testing security team, I've noticed
that many developers still seem to be unfamiliar with how to use the new
version tracking features[1] of the Debian BTS. 

Oddly, this seems to affect bugs about security holes more than regular
bugs. There seems to be some confusion about how to use the BTS to track
what versions of a package fixed a hole and which are still vulnerable,
and people rightly want to be extra careful about not forgetting to fix
security holes in stable. However, more often than not, they end up
shooting themselves in the foot instead by not using the BTS in the way
it is now designed to work.

Here are three simple rules that you can follow to make sure that the
BTS always has correct information about what version of your package
fixes a bug (especially a security hole).

  1. When you fix a bug in a new version of the package, be sure to put
     a correctly formed "Closes: #xxxxx" line in the changelog.

     Do this even if you only fixed the bug for one distribution of
     Debian and it still needs to be fixed for others. Keeping track of
     what versions of a package still have the bug is what BTS version
     tracking is all about. If you use the system as designed, it will
     do the right thing. Trust me. If you don't trust me, trust Colin
     and AJ.

     If you find yourself sending an email to the BTS stating that "the
     fix has been uploaded", you're doing something wrong.

  2. If you forget a changelog entry, or find out about a fix (such
     as a fix for a security hole) after your upload, send mail to
     xxxxx-done@bugs.debian.org as before, but include a "Version:"
     Again, this will allow the BTS, security teams, etc, to track what
     versions of the package still have the bug.

  3. Don't use release tags ("sarge", "sid", "woody", etc) to try to
     indicate what distributions of Debian a bug effects. It doesn't
     mean what it used to mean, and is now mostly useless.
     Instead just close the bug with a "Version:" pseudo-header as
     above, indicating what version of the package fixed the bug. The
     BTS version tracking will do the rest.

There are some other nicities and tricks you can use with BTS version
tracking that are explained in Colin's mail[1], but if you follow the
three rules above you will be 95% of the way toward correctly using the
version tracking features, and you will save a lot of time for people
who use the BTS to check for things like security hole fixes.

I thought I'd conclude with an example of how to do it right, and wrong.
  right: http://bugs.debuan.org/329839
  wrong: http://bugs.debian.org/322133

see shy jo

[1] Which were announced and explained in detail here:

[2] For example:
      To: xxxxx-done@bugs.debian.org
      Subject: new upstream release fixed some security holes

      Version: 2.0-1

      CAN-2005-0000 was fixed in this upstream release.

Attachment: signature.asc
Description: Digital signature

Reply to: