closing older bug reports without looking = bad practice ?

Dave Jones davej at redhat.com
Tue Feb 21 03:53:56 UTC 2006


On Tue, Feb 21, 2006 at 11:26:05AM +0900, Jason Montleon wrote:
 > >I also noticed Dave closes kernel bugs with each kernel release, asking
 > >people to retest. While this might save developers time, it could also
 > >leave real bugs closed as reporter might get tired of re-confirming a
 > >bug for 3 times.

for the record, I don't mass-close bugs with each kernel release.
I put every bug into NEEDINFO_REPORTER state each time I rebase to a
new upstream release (typically every 2-3 months), along with a comment
that the bug will be closed if there's no response within a few weeks.
(Which is more psychological trickery than a threat, chances are I'll
 find something else more important to occupy myself with when the
 'time limit' runs out, leaving the bug in NEEDINFO for even longer)

Over the following few days, _dozens_ of bugs then get closed by the
reporters (sadly there's a bunch that report "yup, is fixed",  but
still leave me to go close the bug for them).
It's a massive timesaver, which allows me to work on bugs that need
attention, as opposed to spending all day triaging.

The only times I've mass-closedbugs are..
- end of life of FC2.  (A few days later, a dozen or so got reopened as FC3 bugs)
  For FC3, there were ~120 kernel bugs left at EOL. I mass-migrated
  all these to FC4 bugs, where the users closed a bunch of them themselves
  a few days later.
- When bugs have been in NEEDINFO states for _months_.
  If the user has got tired reporting 'bug still there',
  there's not a lot more I can do, and closing these bugs
  does 'wake up' a bunch of dormant bugs.

Nothing stops a closed bug being reopened at any point by its reporter.
Whilst people on the Cc of a bug can't reopen a bug they didn't file,
if they make noise in the comments after it gets closed, I'll reopen
them.  This is such a rare occurence that it's not a big time sink.

		Dave




More information about the fedora-test-list mailing list