"I understand that developer resources are limited but shouldn't the bug remain 'Confirmed' until proven otherwise?"
Indeed, that is exactly what happened, the bug remained in confirmed state for a year and a half.
You have to understand that there are 400 bug reports against Ubuntu's X components, with around 200 bugs filed each month. It is very challenging to stay atop the new bugs, let alone the old ones. Fortunately, for natty we did in fact manage to stay more or less atop the bug flood this go around. You can see this from this graph:
Truly investigating bugs takes a considerable amount of time. Deep analysis of a bug can take days of time, and you can see from the numbers (and like you mention in your post) we get way more requests from people to analyze their problems than we have manpower to do. So we focus effort on where we can provide the best bang for the buck. That usually translates to bugs that are confirmed as still issues with the current version (i.e. oneiric), that either we can reproduce ourselves or that have an active reporter who can do testing for us (and is willing to fight for the correct status for a bug), that are severe issues affecting a lot of people, and that we are likely going to be able to fix. (This latter point is why -nvidia and -fglrx bugs like this one tend to get less priority - because they're proprietary codebases, we fundamentally simply cannot legally or technically fix many problems, because the car's hood is welded closed to us.)
"I think the process should be to first ask if the bug still occurs. Then if there are no updates for some time or people can confirm that the bug no longer exists in the newer version then the status can be changed."
Well, basically what you describe is the process we're following here. Maybe it feels like a "smackdown" to have it marked 'Incomplete', but launchpad has special tracking features relating to Incomplete status, which is why I use it - this state (and only this state) has a flag to show when someone has replied to a bug after we've asked a question. Sorry you feel it to be a "smackdown", however as you can see, the process worked here - your "rant" got flagged as an answer and here I am. :-) Unfortunately Launchpad doesn't differentiate between answers from the original reporter vs. any random commenter (I _really_ wish it did...) but this process works.
Anyway, this is probably all TMI, but one rant deserves another I guess. ;-) I don't want you thinking we all just sit around on our thumbs all release and then spam everyone to retest, although I'm sure you must think that!
"I understand that developer resources are limited but shouldn't the bug remain 'Confirmed' until proven otherwise?"
Indeed, that is exactly what happened, the bug remained in confirmed state for a year and a half.
You have to understand that there are 400 bug reports against Ubuntu's X components, with around 200 bugs filed each month. It is very challenging to stay atop the new bugs, let alone the old ones. Fortunately, for natty we did in fact manage to stay more or less atop the bug flood this go around. You can see this from this graph:
http:// www.bryceharrin gton.org/ Arsenal/ Reports/ ubuntu- x-swat/ totals. svg
Truly investigating bugs takes a considerable amount of time. Deep analysis of a bug can take days of time, and you can see from the numbers (and like you mention in your post) we get way more requests from people to analyze their problems than we have manpower to do. So we focus effort on where we can provide the best bang for the buck. That usually translates to bugs that are confirmed as still issues with the current version (i.e. oneiric), that either we can reproduce ourselves or that have an active reporter who can do testing for us (and is willing to fight for the correct status for a bug), that are severe issues affecting a lot of people, and that we are likely going to be able to fix. (This latter point is why -nvidia and -fglrx bugs like this one tend to get less priority - because they're proprietary codebases, we fundamentally simply cannot legally or technically fix many problems, because the car's hood is welded closed to us.)
"I think the process should be to first ask if the bug still occurs. Then if there are no updates for some time or people can confirm that the bug no longer exists in the newer version then the status can be changed."
Well, basically what you describe is the process we're following here. Maybe it feels like a "smackdown" to have it marked 'Incomplete', but launchpad has special tracking features relating to Incomplete status, which is why I use it - this state (and only this state) has a flag to show when someone has replied to a bug after we've asked a question. Sorry you feel it to be a "smackdown", however as you can see, the process worked here - your "rant" got flagged as an answer and here I am. :-) Unfortunately Launchpad doesn't differentiate between answers from the original reporter vs. any random commenter (I _really_ wish it did...) but this process works.
Anyway, this is probably all TMI, but one rant deserves another I guess. ;-) I don't want you thinking we all just sit around on our thumbs all release and then spam everyone to retest, although I'm sure you must think that!