Hi, 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: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ssh&dist=stable If you want to specify a particular version of the package, the URL would look like this instead: http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ssh&version=1:4.1p1-1 The web form at http://bugs.debian.org/ has been updated to offer these options. 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 thanks 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 not. 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 Cheers, -- Colin Watson (for the debbugs team) [cjwatson@debian.org]
Attachment:
signature.asc
Description: Digital signature