bugzilla bugzappers?

Michael Schwendt mschwendt at gmail.com
Fri Nov 5 17:29:09 UTC 2010


On Thu, 04 Nov 2010 09:38:35 -0700, Adam wrote:

> On Thu, 2010-11-04 at 13:28 +0100, Michael Schwendt wrote:
> 
> > > So can someone please explain my why I should continue to try to
> > > improve Fedora by reporting bugs ?
> > 
> > Glad you ask this. The bugzapping script is stupid. It asks the reporter
> > for NEEDINFO when in fact it ought to ask WTF has the packager not
> > responded since Fedora 12?
> 
> you're looking at it through a 'moral' framework when the important
> thing is the 'practical' framework. :) The practical point is that F12
> is about to go EOL which means the bug must be closed...

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

> 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 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?

> 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).


More information about the devel mailing list