On Fri, 05 Nov 2010 13:45:37 -0700, Adam wrote: > > Something is terribly wrong here, if reporter adjusts F12 -> F13 -> F14 > > over a period of N months in reply to the automated NEEDINFO requests and > > still doesn't get any response other than another automated one after > > six more months. > > So, what's your alternative? To keep them open, so as they get older and they continue to affect users, they could be moved up from the bottom of somebody's TODO list. If they get closed, much is lost including test-case attachments, comments, links. Eventually somebody will open a new ticket for F15 and point out that the package is broken since F8. > The underlying problem here is the one > everyone knows about: we don't have enough manpower to fix all bugs. > Given that, why is it better to leave them rotting away for years than > to close them? Better would be to fix the bug in the software/package and remove the cause of new tickets or dupes created by ABRT. Who can tell whether lack of response is really due to lack of manpower? And not due to other factors? For example, there's a crash in librsvg2, which affects multiple apps that use this library, including Nautilus. There have been multiple reports about it. Including an upstream ticket created by me. Including a comment on what is wrong in the source and what would be a work-around. No response so far. http://bugzilla.redhat.com/553069 Other tickets for the same issue are in EOL NEEDINFO state meanwhile. For me, even with provenpackager access, it's not clear how to proceed even if the issue affects one of my packages, too. And whereas I would fix such an issue in my own packages, there are lengthy documents like https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages that make me insecure. > [...], you want a list > of packages for which our track record of fixing bugs is not great, > right? Okay, supposing we make such a list, what is it you want to do > with it? Not right. I (and to the best of my knowledge also other packagers I've talked to) could use such a list and look for packages that need help. Based on actual statistics instead of randomly poking in bugzilla or in bugz.fedoraproject.org pages. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
