On Fri, 2010-11-05 at 21:37 +0100, Michael Schwendt wrote: > On Fri, 05 Nov 2010 12:30:41 -0700, Adam wrote: > > > 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? > > Then why should the reporter take action in reply to the NEEDINFO > bugzapping request? > > 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? > > 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. > > Look in the archives. It's not the first time I've criticized what this > bugzapping script does. It has stopped me from filing lots of issues, > both with regard to packaging bugs as well as other problems, because > I simply cannot handle the flood of NEEDINFO requests. If I remember > correctly, this predates your involvement in Fedora. (And John comes > up with so much stuff, hardly anyone will handle it anyway.) Yes, we've been doing it for a while. I keep saying it's not perfect. But what's your alternative? 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? > > If the bug's not reproducible, how is anyone going to fix it? > > Or know that it's been fixed? > > Praise ABRT! In many cases, complete backtraces in conjunction with the > source code reveal programming errors - sometimes embarassing ones. > Not always, but if nobody skims over the problem reports, nobody can tell > whether a reported bug is interesting or not. Well, in the abrt thread we have someone arguing that abrt reports are almost always useless without steps to reproduce (their words, not mine)...clearly, everyone doesn't agree here. > > > 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 :>) > > The sentence is complete. Probably writing it was wasted time, because > apparently *you* are not interested in feedback or in ideas, which might > be more helpful than hiding bugs under the carpet. Saying 'I want someone to make this list so I can look at it' isn't really useful feedback or ideas, it's demanding someone else do work on your behalf. Which historically speaking is not the best way to make sure it gets done. I have trouble parsing that sentence, my eyes glaze out somewhere in the middle of the fourth line, but if I'm reading it right, 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? -- 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
