On 2018-10-21 20:25:47 -0400, James McCoy wrote: > On Sun, Oct 21, 2018 at 11:33:11PM +0200, Vincent Lefevre wrote: > > 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.
This is what I did, but the goal was to prevent the bug from being archived. > > 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. But here, this was for the second effect: "The bug also should not be archived until it is fixed in the release." -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
