On Sun, Oct 21, 2018 at 11:33:11PM +0200, Vincent Lefevre wrote: > On 2018-10-21 08:17:33 -0400, James McCoy wrote: > > There was a version of the package with the bug in experimental. > > No, the bug just has: > > Found in versions subversion/1.9.7-2, subversion/1.9.5-1 > > where both 1.9.5-1 and 1.9.7-2 were in unstable.
The first version that had the fix was uploaded to experimental, so it appears that in combination with the existing release-specific tags (sid, stretch) is what causes the issue Andreas was trying to fix. > > This was an attempt by Andreas to fix the tracking with respect to > > that. Quoting his response when I asked him about it: > > > > > The bug was tagged sid buster, and has a version in experimental. > > > UDD displays these bugs in an inconclusive way as "does not affect > > > experiental", which can have two causes: > > > * the bug is fixed in experimental > > > * the bug exists in experimental, but someone forgot to tag it accordingly > > If the only reason is that the bug is fixed in experimental, I don't > think that the bug should be tagged "experimental". AFAIK, the right > tag for that is "fixed-in-experimental". No, fixed-in-experimental is primarily from pre-version tracking days. It's not really relevant anymore, since the version tracking already implicitly provides the same information. > > > Therefore I tag all the ambiguous bugs + experimental, and let the fixed > > > versions decide whether the problem actually exists in experimental. > > > > The root of the problem is that you tagged this bug "sid stretch" in the > > first place. Please don't use these tags. Just let the version > > tracking do its work. > > > > The tags are only useful to indicate that, although the buggy version is > > present in multiple releases, only the tagged releases are affected. > > I had added these tags with the hope of a fix for stretch (in addition > to sid), Then suggest that in the bug report rather than using release tags. > as upstream planned a backport to the 1.9 branch. This bug > occurs only with some particular files of some repositories, thus is > uncommon, but when it can occur, it is rather annoying. > > In the meaning of these tags has changed, then > > https://www.debian.org/Bugs/Developer#tags > > should be updated. The description seems pretty accurate to me: These are release tags, which have two effects. When set on a bug, the bug can only affect the particular release (though it may also affect other releases if other release tags are set) but otherwise normal buggy/fixed/absent rules apply. The bug also should not be archived until it is fixed in the release. "the bug can only affect the particular release" is obviously untrue for this bug. It's a bug in the software which will affect any release which contains that version. The canonical example for using the release tags is failing to build due to some change in a dependency. That's not specific to the version of the package the bug is filed against, but is due to a change in the set of software that's in the specific release. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
