bugzilla bugzappers?

[Adam Williamson]

On Fri, 2010-11-05 at 18:29 +0100, Michael Schwendt wrote:

> It is inefficient, if some time later another user needs to report the
> same issue only to get ignored, too. It is not encouraging our users to
> spend time on reporting bugs and on replying to NEEDINFO or other
> questions in the tickets. The warning that the ticket may be closed
> could have been given _much_ earlier, e.g. after two months of silence
> with no reply from the maintainer(s). Or at release time of F(N+1)
> Beta. Much worse if it's the second time a ticket is closed because of
> EOL. It's just poor form to ignore a user's bug report completely. I've
> received bugzapping mails for various issues, including packaging
> mistakes that have not been examined since F12. For example:
> http://bugzilla.redhat.com/516352

Closing the bug *isn't* ignoring it. Leaving it open and doing exactly
nothing about it, which is what would happen if we didn't auto-close
bugs, is ignoring it. If the bug hasn't had any attention for the last
year and a half it's not particularly likely to magically get it now, is
it?

If we don't auto-close bugs we wind up with a huge pile of ancient bugs
which just gets in the way of people who want to come along and actually
clean up the bug list for a package. It's harder to do that if you're
looking at reports from the Stone Age.

> > UNLESS it's
> > still present in later releases. It's the reporter who is most likely to
> > be able to say whether it is, therefore, we ask the user to check and
> > update the bug, not the maintainer.
> 
> This is ridiculous because of very poor timing 

John always posts the schedule for housekeeping tasks to test list (I
think possibly devel list too, I forget) and asks for feedback. He never
seems to get any.

> and because bugs may not
> always be reproducible. What makes you think the reporter can find the
> free time to handle a flood of EOL tickets?

I don't think they always will, but the alternative is worse. If the
bug's not reproducible, how is anyone going to fix it? Or know that it's
been fixed?

> > It may be 'fairer' to set needinfo
> > maintainer, but the result sure wouldn't be as good in practical terms,
> > because the maintainer is less likely than the user to actually be
> > able/inclined to provide the required data.
> 
> I'd like to see the list of Fedora packages, which are under-maintained
> and actually suffer from issues, which are not fixed by the Fedora Project
> and are not fixed in the upstream code base either (because a packager
> doesn't even forward problem reports to upstream trackers or because
> upstream development doesn't get rid of defects "magically" with lots of
> code rewrites).

And I'd like a gold-plated pony. If you'd like to see the list, why not
create it? I don't think anyone else has it lying around just ready to
produce on demand.

(Unless there was meant to be a second part to this sentence and you got
lost somewhere in the middle :>)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net