Why was a kernel-2.6.34 pushed to updates that had un-addressed bugs.

["Jóhann B. Guðmundsson"]

  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