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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
