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