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

BTS version tracking


A frequently requested feature for the bug tracking system in recent years
has been the ability to track which bugs apply to which distributions,
so that, eg, maintainers and others can tell which bugs that have been
fixed in unstable still apply to packages in testing or stable.

This has now been implemented. 

It is quite a far-reaching change, and you will probably want to adjust
the way you deal with the BTS as a consequence. Please read this mail
all the way through so that you know what's happened. In most cases you
should be able to just continue using the BTS as you have been - in
particular, filing bugs with reportbug and closing them by adding
entries in the changelog of new uploads will keep on working as before.
Our priority over the next period will be making sure the changes don't
have any nasty corner-cases and the BTS can still be reasonably used by
maintainers to track bugs in their packages.

Here's how it works.

To find out what bugs apply to, say, the version of ssh in stable, use
the following URL:


If you want to specify a particular version of the package, the URL
would look like this instead:


The web form at http://bugs.debian.org/ has been updated to offer these

When you report a bug or add more information to an existing bug, the
Version: pseudo-header is now recorded as a "found" version. Likewise,
when you mail -done or -close, the Version: pseudo-header (or
Source-Version:, in order to refer unambiguously to source packages) is
recorded as a "fixed" version.

A number of changes have been made to control@bugs.debian.org [1] to
support this. Firstly, the 'close' and 'reassign' commands now take
extra version arguments, as follows:

  close 1234567 1.1
  reassign 1234567 example-package 2.0-1

The 'reopen' command takes an optional submitter argument, so it was
difficult to get a version in here unambiguously. Instead, we've
introduced a new 'found' command, which says "I've found the bug in this
version of the package". You can use this whether the bug is open or
closed; if the bug's closed and you give a version more recent than the
last recorded fixed version, the bug will be considered open again.

  found 1234567 1.3-2

'found' is now preferred to 'reopen' except when reopening bugs that
were closed without a version (e.g. closed as invalid).

When you mail nnnnnn-done without Version:, i.e. the old way of closing
bugs, the bug tracking system does approximately what it always did and
records the bug as closed for all versions of the package containing it.
Obviously, this loses the benefits of version tracking, and is now
intended only for pseudopackages and for closing bugs that were never
bugs to start with. It's still OK to use 'reopen' in the traditional way
to reopen such bugs in a versionless way, although the 'found' control
command without a version number works too.

The archive maintenance software was updated some time ago to include
Source-Version: pseudo-headers when closing bugs, which means that all
this works automatically. Furthermore, we've run a script over all
existing bugs that tries to guess correct found and fixed versions from
their history. This will certainly have made some mistakes, but it
should be a reasonable start.

The meaning of the distribution-specific tags (woody, sarge, and so on)
has changed. We now have a good mechanism to say "this bug has been
fixed since sarge was released", so there's no longer any need to have a
tag for that. However, it's still useful to have a tag to mark bugs that
you're planning to fix in, say, a stable point release. So, for
instance, the sarge tag now means "don't archive this bug until it has
been fixed in a version in sarge".

The fixed-in-experimental tag is now deprecated and will be disabled as
soon as it's practical to do so.

By default, pkgreport.cgi will show as open all bugs that have no
recorded fixed versions. This is more or less the same as its existing
behaviour, and is designed to ensure that bugs don't get lost in obscure
listings off to the side somewhere. If you supply a 'dist' or 'version'
CGI parameter, then it will display the bug as open if the version is
based on one in which the bug was found and not based on one in which it
was fixed. The "based on" part is determined by reading lists of
versions from package changelogs, and using those to build up a picture
of any branches in the package's development. For example, security
updates to stable are usually a branch.

This definition of "based on" has an interesting side-effect, namely
that the "fixed" tag is no longer needed for non-maintainer uploads.
NMUs simply close the bug, and if the next maintainer upload fails to
acknowledge the NMUs by incorporating their changelog entries then the
bugs will magically reopen themselves because the most recent version in
unstable doesn't contain the fix. Thus, it is very important to follow
what's been best practice up to now anyway and incorporate changelog
entries from NMUs. You may also wish to merge in changelog entries from
security updates at the appropriate point in your changelog when you
apply the same fix to unstable.

So, to wheel out some examples, a typical exchange might start off like
this, with a user filing a bug:

  From: reporter@example.com
  To: submit@bugs.debian.org
  Subject: hello says "goodbye"

  Package: hello
  Version: 2.1.1-1


The maintainer notes that this bug also occurred in an earlier version
of hello:

  From: hello@packages.debian.org
  To: control@bugs.debian.org
  Subject: add found version

  found 999999 1.3-16

The maintainer fixes the bug:

  From: hello@packages.debian.org
  To: 999999-done@bugs.debian.org
  Subject: fixed in new version of hello

  Package: hello
  Version: 2.1.1-2

  I have uploaded a new version of hello which fixes your bug. The
  changelog follows.

Now, http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=hello&dist=stable
will show the bug, because stable contained 1.3-18; &dist=testing will
show it until such time as 2.1.1-2 is promoted to testing.
&dist=unstable, &version=2.1.1-2, and the default view, however, will

This is a new facility, and you will certainly notice some deficiencies.
Please bear with us as we polish this up, and report problems as bugs
against the bugs.debian.org pseudo-package. In particular, a few obvious
things remain to be done:

  * Bug expiry (archival) is currently disabled, since the system to
    archive bugs based on their distribution tags has not yet been
    written. I don't expect this to take too long to sort out.

  * NMU handling still needs a better user interface, although you can
    ask for bugs in specific versions of individual packages to work
    around this.

Thanks to Anthony Towns for a great deal of discussion and design work,
particularly at Debcamp 3 where we hashed out several details and a good
part of the implementation, and for the changelog-based specification of
"based on" which is crucial to making this all work. Thanks to James
Troup for adding the necessary hooks to katie.

[1] http://www.debian.org/Bugs/server-control


Colin Watson (for the debbugs team)                [cjwatson@debian.org]

Attachment: signature.asc
Description: Digital signature

Reply to: