Re: Processed: found 939940 in 0.5.1+git20160404-1, tagging 939940, found 939950 in 5.0.0.2456-1, tagging 939950 ...

[Andreas Beckmann <anbe@debian.org>]

On 20/11/2019 23.24, Rene Engelhard wrote:
> tag 939950 - sid
> thanks

This is not the way the these tags work.

Codename tags only limit the releases where a bug is relevant, they
don't say whether a bug still exists (otherwise uploading a fix or
having it migrate to testing would require updating the tags). Existence
of bugs is given by "found" and "fixed" versions.
Tags are usually used where stable and (testing or sid) have the same
version, s.t. "found" alone is not able to limit a RC bug to the current
development cycle.

In your case:

>>> found 939956 0.6.2-1
>> Bug #939956 {Done: Rene Engelhard <rene@debian.org>} [src:liblangtag] liblangtag: fails to build with gtk-doc 1.32
>> Marked as found in versions liblangtag/0.6.2-1.

The bug did not have any "found" version, i.e. all versions smaller than
the fixing 0.6.3-1 have this bug. While this is technically correct, it
creates no or noisy version graphs in the BTS. As no versions older than
the one in testing will be exposed to gtk-doc 1.32, I set the bug to the
version in testing...

>>> tags 939956 + sid bullseye
>> Bug #939956 {Done: Rene Engelhard <rene@debian.org>} [src:liblangtag] liblangtag: fails to build with gtk-doc 1.32
>> Added tag(s) sid and bullseye.

... which is the same as in stable. But since stable won't see gtk-doc
1.32, the bug is irrelevant there and therefore should not be RC in
buster, but only RC for the bullseye(+x) development cycle(s). Therefore
I'm also setting "relevant in sid and bullseye" (implying "not relevant
in any release before stretch, stretch, buster, experimental" regardless
what "found" and "fixed" say)

> 
> Obviously not:
> 
> rene@frodo:~$ rmadison liblangtag
> liblangtag | 0.5.1-3       | oldoldstable    | source
> liblangtag | 0.6.2-1       | oldstable       | source
> liblangtag | 0.6.2-1       | stable          | source
> liblangtag | 0.6.2-1       | testing         | source
> liblangtag | 0.6.3-1       | buildd-unstable | source
> liblangtag | 0.6.3-1       | unstable        | source
> liblangtag | 0.6.3-1       | unstable-debug  | source
> 
> Sid is *NOT* affected.
> 
> (and 0.6.3-1 fixed it.)
> 
> If you do stuff, do it correct.

Having a bug tagged only "bullseye" without "sid" raises the question
"Why was this never relevant for sid?"

Andreas

PS: tagging "sid bullseye" where stable and testing have different
versions is redundant since a "found" version would be sufficient.

PPS: tagging "sid bullseye" implies "not experimental" which is usually
not what you want (udd marks the bug as "not-found-in-experimental"
regardless of whether it was fixed there) - I'm usually adding the
"experimental" tag if I encounter unarchived bugs tagged "sid bullseye"
with a version currently in experimental