Re: BTS version tracking
On Tue, Aug 16, 2005 at 07:47:01AM +0200, Mike Hommey wrote: On Mon, Aug 15, 2005 at 03:41:43PM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Aug 14, 2005 at 02:00:04PM +0200, Mike Hommey wrote: On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson [EMAIL PROTECTED] wrote: (...) 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 nn-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. I was wondering, what is the correct way to handle when you're stupid and close the wrong bug in changelogs ? (like i did with #321876, when i intended to close #321976) AIUI, this falls under the use case described above for the found control command. In the case i'm referring to, the bug is said to be fixed for a particular version of *my* package, not of the bug package. If I say it is found for a version, it will be found for a version of the bug package, right ? Or maybe one can prepend package/ to the version number ? Uh... no idea. Try it and see, and report back? :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: BTS version tracking
On Sun, Aug 14, 2005 at 02:00:04PM +0200, Mike Hommey wrote: On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson [EMAIL PROTECTED] wrote: (...) 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 nn-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. I was wondering, what is the correct way to handle when you're stupid and close the wrong bug in changelogs ? (like i did with #321876, when i intended to close #321976) AIUI, this falls under the use case described above for the found control command. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: BTS version tracking
On Mon, Aug 15, 2005 at 03:41:43PM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Aug 14, 2005 at 02:00:04PM +0200, Mike Hommey wrote: On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson [EMAIL PROTECTED] wrote: (...) 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 nn-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. I was wondering, what is the correct way to handle when you're stupid and close the wrong bug in changelogs ? (like i did with #321876, when i intended to close #321976) AIUI, this falls under the use case described above for the found control command. In the case i'm referring to, the bug is said to be fixed for a particular version of *my* package, not of the bug package. If I say it is found for a version, it will be found for a version of the bug package, right ? Or maybe one can prepend package/ to the version number ? Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
- Forwarded message from Mike Hommey [EMAIL PROTECTED] - From: Mike Hommey [EMAIL PROTECTED] Subject: Re: BTS version tracking To: Colin Watson [EMAIL PROTECTED], [EMAIL PROTECTED] I'm really dumb today, I managed to send that to a wrong address. Additionally, I also managed to re-close the wrong bug (see below). I should just stop debian work for today. On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson [EMAIL PROTECTED] wrote: (...) 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 nn-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. I was wondering, what is the correct way to handle when you're stupid and close the wrong bug in changelogs ? (like i did with #321876, when i intended to close #321976) Mike PS: The recent changes to the BTS (version tracking, block functionality...) really rock. - End forwarded message - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
On Wed, Jul 20, 2005 at 01:45:03PM +0100, Colin Watson wrote: On Tue, Jul 19, 2005 at 10:34:23PM -0700, Brian Nelson wrote: What if the maintainer uploads a version, say 1.3-2 (which is still the most recent version), which supposedly fixes bug 1234567. However, I test it and find that it's actually not fixed. Presumably, I would do: found 1234567 1.3-2 However, since 1.3-2 is equal to the current version, the BTS would erroneously think that the bug is fixed. That does seem to match reality: http://bugs.debian.org/316089 Yes, this is a bug in version tracking: it's a canonicalisation problem between various internal representations of versions in debbugs, reported as bug #319037. Fortunately I don't think it's *too* hard to solve ... This should now be fixed, and fortunately only a few bugs were bitten by this. I've repaired them. There may still be a few broken corner cases in the case of packages that have used dpkg-gencontrol's -v switch to produce binary packages with a different version from their source package (which is where most of the really hairy corner cases in version tracking show up). Please report these if you run across them. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
Le Lun 18 Juillet 2005 23:36, Matthew Palmer a écrit : On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: 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. May I just say, to Colin, Anthony, James, and anyone else who had the slightest bit to do with implementing this functionality: Thank You. Same here ... this is *really* a relief -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoQ6bxQET02.pgp Description: PGP signature
Re: BTS version tracking
On Tue, Jul 19, 2005 at 10:34:23PM -0700, Brian Nelson wrote: Colin Watson [EMAIL PROTECTED] writes: 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 Shouldn't that be, you give a version more recent than *or equal to* the last recorded fixed version...? Mm, right, that's what I meant to say. What if the maintainer uploads a version, say 1.3-2 (which is still the most recent version), which supposedly fixes bug 1234567. However, I test it and find that it's actually not fixed. Presumably, I would do: found 1234567 1.3-2 However, since 1.3-2 is equal to the current version, the BTS would erroneously think that the bug is fixed. That does seem to match reality: http://bugs.debian.org/316089 Yes, this is a bug in version tracking: it's a canonicalisation problem between various internal representations of versions in debbugs, reported as bug #319037. Fortunately I don't think it's *too* hard to solve ... -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
On Mon, Jul 18, 2005 at 10:28:06PM +0200, Andreas Barth wrote: * Colin Watson ([EMAIL PROTECTED]) [050718 17:21]: The BTS records that bug #NN was fixed in 1.1-sarge1 and 1.3, and let's say the bug was found in version 1.1. Since it has the changelogs (it gets these from ftp-master), it can build up a tree of which package versions are based on which other package versions, which in this case looks like this: How does the BTS cope with versions that are not available from ftp-master, but where the maintainer adds found in for them? It records them for possible future reference, but otherwise ignores them. Unrecognised fixed-in versions are similarly mostly ignored, although the CGI scripts will sometimes use the presence of a fixed-in version *somewhere* as an indicator that the bug is fixed. This is only as a last-resort fallback if no better information is available, though. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: 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. May I just say, to Colin, Anthony, James, and anyone else who had the slightest bit to do with implementing this functionality: Thank You. It's a tricky problem, both on the UI and infrastructure sides of the coin, it must have taken quite some time to put it all together, and I'm glad that we've got it. This will make debbugs even better to use now. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
Colin == Colin Watson [EMAIL PROTECTED] writes: Colin A frequently requested feature for the bug tracking system Colin in recent years has been the ability to track which bugs Colin apply to which distributions, so that, eg, maintainers and Colin others can tell which bugs that have been fixed in unstable Colin still apply to packages in testing or stable. Colin This has now been implemented. Congratulations for anyone involved in writing this much requested feature. Not only did you implement it, but it appears you have considered many different situations. Now my top wishlist is support for this new system in apt-listbugs grin. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
Colin Watson [EMAIL PROTECTED] writes: [...] 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 Shouldn't that be, you give a version more recent than *or equal to* the last recorded fixed version...? What if the maintainer uploads a version, say 1.3-2 (which is still the most recent version), which supposedly fixes bug 1234567. However, I test it and find that it's actually not fixed. Presumably, I would do: found 1234567 1.3-2 However, since 1.3-2 is equal to the current version, the BTS would erroneously think that the bug is fixed. That does seem to match reality: http://bugs.debian.org/316089 -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: A number of changes have been made to [EMAIL PROTECTED] [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 How is a bug that's fixed in more than one version handled? For example, a security bug fixed in foo 1.1-sarge1 and foo 1.3. Assume 1.1 and 1.2 have the bug. -- Rob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
On Mon, Jul 18, 2005 at 08:35:45AM -0600, Rob Sims wrote: On Mon, Jul 18, 2005 at 12:06:29PM +0100, Colin Watson wrote: A number of changes have been made to [EMAIL PROTECTED] [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 How is a bug that's fixed in more than one version handled? For example, a security bug fixed in foo 1.1-sarge1 and foo 1.3. Assume 1.1 and 1.2 have the bug. So, foo 1.1-sarge1's changelog will look like this: foo (1.1-sarge1) stable; urgency=high * fix security bug in sarge (closes: #NN) -- Security Team [EMAIL PROTECTED] DATE foo (1.1) unstable; urgency=low * last upload before sarge -- Maintainer [EMAIL PROTECTED] DATE ... while foo 1.3's changelog will look like this: foo (1.3) unstable; urgency=high * fix security bug (closes: #NN) -- Maintainer [EMAIL PROTECTED] DATE foo (1.2) unstable; urgency=low * add a feature -- Maintainer [EMAIL PROTECTED] DATE foo (1.1) unstable; urgency=low * last upload before sarge -- Maintainer [EMAIL PROTECTED] DATE The BTS records that bug #NN was fixed in 1.1-sarge1 and 1.3, and let's say the bug was found in version 1.1. Since it has the changelogs (it gets these from ftp-master), it can build up a tree of which package versions are based on which other package versions, which in this case looks like this: 1.1 -- 1.1-sarge1 \ 1.2 -- 1.3 Given that, it's easy to deduce that the bug affects both 1.1 and 1.2, but doesn't affect 1.1-sarge1, 1.3, or any version based on those (unless more information shows up, e.g. the bug recurs for some reason). If you ask for bugs in an affected version, or in a distribution that contains an affected version (let's say 1.2 is in testing and you ask for http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=foodist=testing), the bug shows up as open; if you ask for bugs in an unaffected version, or in a distribution that contains an unaffected version, the bug shows up as closed. Obviously, this is a fairly simple case and it can get a lot more complicated than that in practice ... Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BTS version tracking
* Colin Watson ([EMAIL PROTECTED]) [050718 17:21]: The BTS records that bug #NN was fixed in 1.1-sarge1 and 1.3, and let's say the bug was found in version 1.1. Since it has the changelogs (it gets these from ftp-master), it can build up a tree of which package versions are based on which other package versions, which in this case looks like this: How does the BTS cope with versions that are not available from ftp-master, but where the maintainer adds found in for them? Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
