On Fri, 2010-11-05 at 18:29 +0100, Michael Schwendt wrote:
It is inefficient, if some time later another user needs to report
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:
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
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
> 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
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 :>)
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org