Re: the new style "mass tirage" of bugs
John Goerzen writes ("Re: the new style "mass tirage" of bugs"):
> Here's the thing. If bugs I submit actually get looked at by a human, and
> humans are fixing a reasonable percentage of bugs submitted, I don't mind
> testing things out on new versions whenever I can.
I think this is a key point.
I've had a number of cases recently where very old bugs of mine have
had responses apparently by people other than the maintainer saying
`can you reproduce this' or `is this still relevant in the new
version'. These messages are IMO useless, in the vast majority of
cases.
A good test is: what would I do if I were both the maintainer and the
bug submitter ? Looking at it that way avoids getting confused, and
avoids adopting approaches which just shuffle work about or which even
create more work.
If I have reported a longstanding bug in a package of mine, I don't
usually say to myself `oh look this is years and years old let me see
if I can still reproduce it so I can just forget about it if not'.
Rather I'll ask `has anything changed in the package which one might
expect to have a bearing on this bug'. If the answer is `no' then the
bug should stay open until I have effort to actually investigate it.
That this might take months or years if the bug is not very important.
If the answer is `yes, the package has changed', then the next
question is `what is the best way forward'. Sometimes it will be
obvious that the code which had the bug has been entirely removed, so
that the bug report no longer serves a useful purpose. At other times
a quick glance at the relevant code changes shows that actually the
changes couldn't fix the reported symptoms. And then there are cases
where the best approach is to try it again with the new version. etc.
But these decisions cannot be made by unskilled `triagers' who just go
around sending emails to what they think of as `stale' bugs.
Of course there are packages (OOo and Mozilla are probably examples)
which are so huge and so full of bugs that dealing properly with all
of the bugs is impossible. In particular, if a package has so many
bugs, or is generally so large or in such poor shape, that it is
inconceivable that anything but a small inority will ever be properly
investigated and fixed, there is no point recording minor bugs in the
Debian BTS. That just serves to clutter the bug listings to no useful
effect.
So I don't mind it at all when then Mozilla maintainers say `is it
still doing this crazy thing'. After all I don't even bother
reporting most of the bad things Mozilla does; one-offs definitely
don't make the cut. If I can't reproduce it then if I were both
submitter and maintainer I wouldn't spend any more time on it. So
then just closing it is fine.
Whether or not a package is like this is probably a question for the
maintainer to decide - but if the number of bugs is only a few dozen
then I think saying the package is unmaintainable is not a reasonable
point of view.
Ian.
Reply to: