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