On Fri, 2010-11-05 at 23:09 +0100, Michael Schwendt wrote: > 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. How are we to know they continue to affect users? > 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. It's not lost, it's all there; the bug is just marked CLOSED. It can be re-opened if it turns out to be necessary. People file new bugs without looking for duplicates all the time anyway. We usually only catch dupes through triage efforts or through the developer noticing that a bug looks like an older one. > > 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? we've only had abrt for a short time; we've had the EOL process much longer. We wouldn't suddenly stop needing the EOL process if abrt wasn't around. lack of manpower is the ultimate explanation for lack of attention to bugs whenever I've gone to the trouble of tracking down an explanation. What other explanation would you posit? > 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. None of this feels like it has much to do with the EOL process. How exactly would changing the EOL process help this? > > [...], 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. okay, so that's a sensible idea. It wasn't at all obvious, to me anyway, from your initial post :) -- 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
