Re: Bug Tags
>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
Anthony> Actually, "stable" is implied by the state of the
Anthony> archive, the version of the package a bug is filed
Anthony> against, and (possibly) the version/s of the package that
Anthony> fix the bug. It's reasonably feasible to just make the
Anthony> BTS do all this inferring itself, and not need a separate
Anthony> release tag at all.
You need to be able to tell if it has been fixed or not, in unstable.
IMHO there are three common questions:
1. user: what bugs exist in version x of package y?
2. user: will upgrading help? if I upgrade, do I need to upgrade to
stable, or unstable to fix the problem?
3. maintainer: what bugs exist in unstable that need fixing? (note:
by unstable, I mean the latest unstable, and you shouldn't have to
reset all woody tags when woody is released)
I think a better way to solve this would be an extra field, eg:
open-for-versions: >=1.6-4, <<1.6-6
fixed-for-versions: >=1.6-4.potato.0, <=1.6-4.potato.9
which might come about as follows:
1. package 1.6-4 released in potato.
2. potato released.
3. new version (1.6-5) released for woody.
4. security bug found, bug opened, with "open-for-versions: >= 1.6-4".
5. new package 1.6-4.potato.1 uploaded to potato, and 1.6-6 uploaded
to woody.
6. when package is uploaded, sufficient information is extracted
from the package to automatically close the bug, as shown above.
--
Brian May <bam@debian.org>
Reply to: