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 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 firstname.lastname@example.org as before, but include a "Version:" pseudo-header. 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, 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  Which were announced and explained in detail here: http://lists.debian.org/debian-devel-announce/2005/07/msg00010.html  For example: To: email@example.com Subject: new upstream release fixed some security holes Version: 2.0-1 CAN-2005-0000 was fixed in this upstream release.
Description: Digital signature