On 09/02/2010 09:56 AM, Dennis J. wrote: > I think the question is how regressions are prioritized. For me the issue > is that my Radeon card has been working perfectly on F11 but had a major > performance regression with F12 that makes the system too slow for regular > use. I filed a bug with lots of information and a sysprof profile that > shows extreme differences in behavior between the F11 system and a current > F14 build but this hasn't been dealt with since I posted that profile. > The result is that I'm pretty much stuck on F11 for now which is > frustrating not because I expect any particular fancy features to work but > because I bought this card since it was so well supported and working > nicely on F11. Also the mobile version of the same gfx-chip doesn't have > this issue on my notebook so I have a hunch that this isn't some major > problem but something that could potentially be solved relatively quickly. On bug 617683 is one possible explanation on why users suffer hw regression with the kernel which hopefully will be discussed and dealt with on this years kernel summit. "This firmware isn't *in* the upstream linux-firmware tree. The author of the driver in question has made his driver require a new firmware without putting that firmware *anywhere* sensible." No movement on bug reports does not necessary mean that the bugs are not being worked on. Yes in ideal world they would comment on it being looked at or what not and it's frustrated that they dont comment on the status of the bug in question and actually close bugs when they are fixed ( often that's not the case and reports get cleaned up by EOL process instead of being closed as FIXED ) however this problem goes both ways with reporters not responding to et all or do not respond in timely manner to a NEEDINFO request from maintainer, which is real problem because finally when the maintainer has reach your bug on his priority list ( As I have mentioned before reporters and triagers changing priority and severity status on a bug report means nothing to a maintainer ) and has time to look at and fix the issue at hand everything grinds to a halt because the NEEDINFO has not been responded to so he moves on and may or may not put you at the bottom at the stacks of reports to deal with. To actually see the extent and identifying problem(s) and regressions ( you could notice reporting trends with components ) and deal with it accordingly we need to gather and make public bugzilla stats for components. Making those stats public ( pretty sure you can easily gather them in bugzilla ) is more a political issue then technical one. For one we share bugzilla with Red Hat which I like since I'm using both RHEL and Fedora ( I personally would like to keep it that way ) but that sharing limits us a bit for doing things like we want it and then it's the issue with maintainers may not want to make their good or not so good bugzilla stats public.. JBG -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
