Re: When to close bugs on old package versions
On Tue, 28 May 2002, Sean 'Shaleh' Perry wrote:
> > And what about when, for instance, potato is replaced as the stable distro
> > by Woody? Should the bug be closed then because it's no longer relevant?
> > Perhaps it's closed automatically because it's tagged 'Potato', I don't
> > know.
> >
> > Anyway, just trying to think my way through a few issues with the BTS and
> > the hows, whys, and wheretofores of bug handling when there are multiple
> > simultaneous versions of a package for bugs to be tracked on.
>
> setting it to Potato shows that it has either been fixed or obsoleted in more
> recent versions.
But a bug marked 'potato' but that won't be fixed because it's not security
critical - is that still a bug? I mean, it is an issue with the package,
but because it only affects potato (or, by extension, the stable
distribution, whatever it may be) it's never going to get fixed, so what is
to be done with the bug? Do we just leave them open forever, or should they
be marked somehow? I think that tagging them somehow is the way to go - the
Potato tag could serve that role, I guess, but that tag also flags bugs
which may be security or RC.
> wontfix implies this is not a bug but users think it is or sometimes 'cantfix'
> for a bug which exists, is known, but requires a complete rewrite and
> reimplemenation to fix.
That's not the way I read the BTS docs:
"wontfix
This bug won't be fixed. Possibly because this is a choice between
two arbitrary ways of doing things and the maintainer and submitter
prefer different ways of doing things, possibly because changing the
behaviour will cause other, worse, problems for others, or possibly
for other reasons."
To my way of thinking, the only part of that description which is definite
is 'This bug WON'T be fixed.' The rest looks like examples of usage, not
the definitive description of the tag.
--
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer
mjp16@ieee.uow.edu.au
--
To UNSUBSCRIBE, email to debian-mentors-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: