Re: What to do with the very old bugs? [Was: Re: Bug#265831: Obsolete bugreports for 2.4]
On Sat, Oct 28, 2006 at 10:47:38PM -0700, Jurij Smakov wrote:
> On Sat, Oct 28, 2006 at 08:56:34PM +0200, David Schmitt wrote:
> > On Saturday 28 October 2006 07:10, Jurij Smakov wrote:
> > > I just wanted to tell you how much I appreciate the work you are doing
> > > on kernel bugs. It seems like these days nobody on the team has time
> > > left over to do any serious bug tracking, especially deal with the
> > > bugs which are sitting in the BTS forever. I hope you will not be
> > > discouraged by Steve's note. [...]
> >
> >
> > Thank you for your kind words and no worries. Indeed I very much appreciate
> > any feedback, I'd have been surprised, had I not made any error.
> >
> > Looking at the other bug reports I closed with this mail[1], 212678 and 298136
> > seem unresolved too, 304248 is deep within the PCI subsystem arch code while
> > 145504 seems to be fixed but unconfirmed. I'd reopen the first two but I'd
> > let the other two die.
>
> I had a quick look at these bugs, and it seems pretty hopeless that
> submitters will provide any feedback at that point. I think (and I'm
> not neccessarily right :-), so it would be nice if other members of
> the team would comment) that a sensible strategy to handle such
> bugs would be:
I think it is right to ping the submitter, and give him, let's say a month or
so to come back, before completely dismissing him. I have been doing so with
the older powerpc bugs. And i got a reply or two if i remember well.
> 1. Try to figure out whether the bug is solved. That may be done by
> verifying that it is fixed (if feasible) or searching the changelogs,
> current bugs and upstream bugzilla to see whether anything similar has
> been reported. Looking at the git history of relevant files might also
> give a clue, unfortunately it does not extend that far back.
Nice, altough some of the bugs may be hardware related, and with not much
information in the bug report. Those may probably best be simply closed after
the ping period. If the problem still persists, a fresh bug report would be
more helpful anyway.
> 2. If not, usertag the bug with something like
> 'very-old-status-unknown' (using user debian-kernel@lists.debian.org),
> ping the bug, and give some reasonable grace period (1 month?) for
> submitter to respond. Usertags in general are a useful tool, there was
> at some time an effort to create a system of kernel team usertags, but
> AFAIK it never went anywhere (the page is probably still somewhere on
> the wiki though).
Exactly.
> 3. If no ping is received within this time, close the bug. Not quite
> sure what would be the best version to use when closing, however I
> don't really think it matters too much here (it should exist though
> :-).
Fully agreed with this plan. We may bring the bug number down to a manageable
level, and then once this is cleaned up, try to not let this same situation
happen again with an active bug-replying-and-tracking policy.
Friendly,
Sven Luther
Reply to: