We were talking the other day, people were mentioning the bugs they got back from bugzilla recently marked as:
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version.
People were saying that the same problem got the same message a year ago, but it said "Fedora 11" that time. So I have a suggestion, if no one in the support group looks at a bug in 180 days, close it with a DONTCARE status and tell the submitter that no one could be bothered to even look at the bug in half a year. And do the same thing if a bug sits in NEEDINFO for six months, if no one responds in that length of time they probably no longer care.
Users have this unrealistic view that there is a queue of bugs and they get fixed in the order submitted. The truth is that if you don't hear in a month you probably won't ever hear unless someone else reports it and triage catches that they are dups. That doesn't always happen, one of the bugs I had with FC10 was reported as WONTFIX at EOL, and when I tried to reproduce it found that it had been fixed months before and no one bothered to update the bug.
Finally, if someone reports a bug in an app, and the tester finds that it's supposed to work that way, if the documentation says it works some other way don't change it to NOTABUG, change it to a documentation bug. If the conflicting documentation is mentioned in the bug report, take a minute and get it resolved. Please?
My occasional rant when I look at all the time I wasted reporting bugs...
On Tue, 2011-06-28 at 13:11 -0400, Bill Davidsen wrote:
People were saying that the same problem got the same message a year ago, but it said "Fedora 11" that time. So I have a suggestion, if no one in the support group looks at a bug in 180 days, close it with a DONTCARE status and tell the submitter that no one could be bothered to even look at the bug in half a year. And do the same thing if a bug sits in NEEDINFO for six months, if no one responds in that length of time they probably no longer care.
I have to wonder about some bugs, whether it's "don't care" or "don't have a damn clue about programming correctly".
e.g. I submitted a bug, years ago, that was easily demonstrated, and continued through about three different releases of Fedora, and probably still exists.
Put the mouse pointer over a gadget that lets you use the scroll wheel to change the value (e.g. sound volume controls), and the control works the wrong way if it's a horizontally moving slider.
It's even more bizarre when you have dual controls for the same value, as found in the GIMP. Such as a horizontal slider to turn a colour level up and down, with an adjacent number entry box with up and down buttons.
Scroll the wheel up while over the number box, and the numbers go up. Scroll the wheel up while over the horizontal slider, and the numbers go down.
This is a user-interface error that was sheer stupidity in the first place, and galling that it could continue for so long. It affects all applications that let you use the mouse wheel.
Users have this unrealistic view that there is a queue of bugs and they get fixed in the order submitted. The truth is that if you don't hear in a month you probably won't ever hear unless someone else reports it and triage catches that they are dups.
In my case, others noticed the same thing (it's not an obscure error, it's an obvious and consistent one). And they re-opened the bug that got closed off, before I got around to re-reporting it (with each of the Fedora x has reached EOL epochs).
It's been closed off again, for an EOL reason. And I can't install the latest version, *yet*, to see if the issue still exists. Circumstances prevent it for the meantime.
One only hopes the same programmers don't work in the car industry...
The brakes don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model.
On Wed, 2011-06-29 at 22:23 +0930, Tim wrote:
On Tue, 2011-06-28 at 13:11 -0400, Bill Davidsen wrote:
People were saying that the same problem got the same message a
year
ago, but it said "Fedora 11" that time. So I have a suggestion, if
no
one in the support group looks at a bug in 180 days, close it with
a
DONTCARE status and tell the submitter that no one could be bothered to even look at the bug in half a year. And do the same thing if a
bug
sits in NEEDINFO for six months, if no one responds in that length
of
time they probably no longer care.
I have to wonder about some bugs, whether it's "don't care" or "don't have a damn clue about programming correctly".
e.g. I submitted a bug, years ago, that was easily demonstrated, and continued through about three different releases of Fedora, and probably still exists.
I mentioned this problem to Rahul awhile ago. The Bugzilla process is like the "do not track" option in Firefox. You can request an action but the servicing of that request is optional. I find it routine that bugs I report are not fixed.
But if one is an optimist one can take the position that having the bug fixed if you don't report it is an even rarer event.
On Wed, Jun 29, 2011 at 6:27 AM, Aaron Konstam wrote:
But if one is an optimist one can take the position that having the bug fixed if you don't report it is an even rarer event.
Perhaps, but I'm not certain that statistics would back that up. I, too, have reported many things and have only rarely seen reported issues acknowledged, let alone resolved. Lately, I've taken the wait-and-see approach, with approximately the same results. I guess that I'm not an optimist.
As an aside, I'm thinking of bug 531088, which I initially thought would be relatively easy to deal with. To be fair, it seems that many smart and talented individuals have tried to tackle this, but a year and a half on and problems persist in the mail notification applet. I never imagined it could be so complicated. About a year ago, I stopped paying attention to it and consigned myself to just not using the applet. At the time, I figured it would be easier to rewrite the applet completely from scratch than to continue to endure the machinations that were apparently necessary to fix it. And maybe I was right -- with GNOME3 there will probably come a completely revamped mail notification applet that will probably not suffer the problems of the current applet. So I'm hopeful that I will once again be able to be informed of incoming mail, just as soon as I can swallow the pill of GNOME3.
-Alan
Tim wrote:
On Tue, 2011-06-28 at 13:11 -0400, Bill Davidsen wrote:
People were saying that the same problem got the same message a year ago, but it said "Fedora 11" that time. So I have a suggestion, if no one in the support group looks at a bug in 180 days, close it with a DONTCARE status and tell the submitter that no one could be bothered to even look at the bug in half a year. And do the same thing if a bug sits in NEEDINFO for six months, if no one responds in that length of time they probably no longer care.
I have to wonder about some bugs, whether it's "don't care" or "don't have a damn clue about programming correctly".
e.g. I submitted a bug, years ago, that was easily demonstrated, and continued through about three different releases of Fedora, and probably still exists.
Put the mouse pointer over a gadget that lets you use the scroll wheel to change the value (e.g. sound volume controls), and the control works the wrong way if it's a horizontally moving slider.
It's even more bizarre when you have dual controls for the same value, as found in the GIMP. Such as a horizontal slider to turn a colour level up and down, with an adjacent number entry box with up and down buttons.
Scroll the wheel up while over the number box, and the numbers go up. Scroll the wheel up while over the horizontal slider, and the numbers go down.
This is a user-interface error that was sheer stupidity in the first place, and galling that it could continue for so long. It affects all applications that let you use the mouse wheel.
Users have this unrealistic view that there is a queue of bugs and they get fixed in the order submitted. The truth is that if you don't hear in a month you probably won't ever hear unless someone else reports it and triage catches that they are dups.
In my case, others noticed the same thing (it's not an obscure error, it's an obvious and consistent one). And they re-opened the bug that got closed off, before I got around to re-reporting it (with each of the Fedora x has reached EOL epochs).
It's been closed off again, for an EOL reason. And I can't install the latest version, *yet*, to see if the issue still exists. Circumstances prevent it for the meantime.
One only hopes the same programmers don't work in the car industry...
I was really not complaining that bugs don't get fixed, but that the bugzilla process doesn't transition bugs to new states which reflect reality. In the case where no one even looks at a bug for a year, a four month transition to DONTCARE would be good, while the same time in NEEDINFO would indicate apathy on the part of the submitter. It cuts both ways, and the object was to suggest the report state reflect reality, not that any additional effort be put into fixing them.
The brakes don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model. The brakes still don't work. We'll fix that in the next model.
You are being overly harsh. Bugs are fixed if they meet one of two criteria, effecting a large portion of the user base, or effecting a at least one developer.
Am 01.07.2011 16:45, schrieb Bill Davidsen:
You are being overly harsh. Bugs are fixed if they meet one of two criteria, effecting a large portion of the user base, or effecting a at least one developer
how is "a large portion of the user base" qualified?
there are so many peopole out there which never say anything and affected from bad things, so you can't count them really - but they are there!
i see this often in my job where people say "oh yes this does not work since a year" and had never reported, so i can only guess how many others also affected and never did say a word
if there is a bug it should be fixed
On 07/01/2011 08:20 PM, Reindl Harald wrote:
how is "a large portion of the user base" qualified?
there are so many peopole out there which never say anything and affected from bad things, so you can't count them really - but they are there!
i see this often in my job where people say "oh yes this does not work since a year" and had never reported, so i can only guess how many others also affected and never did say a word
if there is a bug it should be fixed
Ideally yes but no distribution has the resources to fix all the bugs reported. That will remain the reality unless there is a influx of a lot more people willing to contribute and help.
Rahul
On Fri, Jul 1, 2011 at 10:58 AM, Rahul Sundaram metherid@gmail.com wrote:
On 07/01/2011 08:20 PM, Reindl Harald wrote:
how is "a large portion of the user base" qualified?
there are so many peopole out there which never say anything and affected from bad things, so you can't count them really - but they are there!
i see this often in my job where people say "oh yes this does not work since a year" and had never reported, so i can only guess how many others also affected and never did say a word
if there is a bug it should be fixed
In theory, yes, in the 'real world' maybe.
Ideally yes but no distribution has the resources to fix all the bugs reported. That will remain the reality unless there is a influx of a lot more people willing to contribute and help.
It depends on where the 'bug' exists. If it is a packaging bug that is specific to Fedora, the original packager should get to work on this first. If they cannot figure it out, then they should be the one(s) to request additional assistance. If the bug is upstream and NOT a Fedora/RedHat product, then the upstream folks should get to work on it first and then they should request assistance. If the bug IS a Fedora/RedHat bug, then RedHat should be looking at this, and if necessary, requesting assistance from the community. If the bug is NEW and the location cannot be determined, then WE the community should be assisting in locating and if necessary troubleshooting why the problem exists. However the problem should exist in one of the three areas above and handed off with all gathered information to the appropriate people.
Now, if a person wants to help design/build/code/etc. then they should be looking and asking one of the three categories above if they can or should assist. Big mistake is diving in without asking first. Been there, done that.
Do not make the assumption, as corrected above, that everything in Fedora is under Fedora's control. There are many 'upstream' projects that are separate from the project. I work with one of them....
James McKenzie
-
Aaron Konstam -
Alan Evans -
Bill Davidsen -
James McKenzie -
Rahul Sundaram -
Reindl Harald -
Tim