Weblog entry #111 for ajt
#111
Reporting Bugs
Posted by ajt on Fri 21 Sep 2007 at 13:47
I run Debian Testing, Lenny at the moment, and I expect things to go wrong from time to time. For a long while I had no OpenGL graphics in X and at the moment though I have Compiz installed it doesn't work.
I try to report bugs but I'm always a bit skittish in case it's because I've done something stupid rather than a bug in the package. This week I've been struggling with nspluginwrapper, to allow 32-bit Mozilla plug-ins in 64-bit mozillas. RealPlayer was working okay, and Flash was working okay in Iceape but not Iceweasel. I almost raised a bug report but at the last minute I tried one more thing and realised I had AdBlock set to block all Flash files!
Additionally, though I know it's a volunteer movement, sometimes it's a bit off putting to submit a bug report and nothing happens at all. So far I'd say I get a response of kinds most of the time but it's probably no more than 75%.
I try to report bugs but I'm always a bit skittish in case it's because I've done something stupid rather than a bug in the package. This week I've been struggling with nspluginwrapper, to allow 32-bit Mozilla plug-ins in 64-bit mozillas. RealPlayer was working okay, and Flash was working okay in Iceape but not Iceweasel. I almost raised a bug report but at the last minute I tried one more thing and realised I had AdBlock set to block all Flash files!
Additionally, though I know it's a volunteer movement, sometimes it's a bit off putting to submit a bug report and nothing happens at all. So far I'd say I get a response of kinds most of the time but it's probably no more than 75%.
Comments on this Entry
My experience is that bug report response on Debian is very good, and usually very quick, but it depends on the bug report, and obviously on the maintainer(s).
I filed a LOT of bug reports relating to spelling mistakes in package descriptions, and these are a low priority item, and tend to be fixed when the next release of the package is made.
Currently 71% of the bugs reported under the email address used for the spelling mistakes (and other issues) have been resolved, most of those outstanding are spelling mistakes in minority interest packages. A fair few of the others that are open, probably ought to be closed because they are resolved by later software.
I have to say that the responses have generally been very positives, and helpful. Even to the point, and the BTS/Debian Developers are not there for this, as being classified as "support". Only on one occasion did I disagree with the result, and that was over an issue of ease of use issue with part of the CUPS printer system, I thought it could be made easier with better defaults the maintainer thought the current documentation sufficient.
Like you I was, and still am, a tad nervous about filing bug reports. If something is clearly wrong (spelling mistakes are a good example) then it is an easy call. But where I've upgraded something, and something odd happens, I am always left wondering "did I fiddle too much?".
Almost universally when I've asked Debian Developers about what I consider borderline cases, they all responded file a bug report.
By filing bug reports;
a) You learn how to file better bug reports.
b) Maintainers learn about how the software is used.
c) There is a documented record of issues, and problems, people experience with that package, even if it isn't actually a bug.
The very worst that will happen is it will get closed promptly, and someone you'll likely never meet will think you are an idiot and wasting their time, and promptly forget about you.
One of the authors of a book on how bad software is, claims all(*) bug reports have a genuine issue in them. The issue may not be a classic bug, and often isn't what is reported, but maybe the software is too hard to use, the documentation is wrong, the defaults wrong, or assumptions are made about the kind of person who will try and use the software. Perhaps the software isn't translated completely into another language.
If in doubt file a report. But remember the golden rule, and file the kind of bug report you would want to receive if it was your package. Sometimes this may be just "I updated package X, it now no longer does Y" because you don't know much about the software but are just a regular user, other times it can include the patch to fix it and why you think it appropriate.
I think that wish-list items don't work too well with Debian BTS, except where the maintainer is also the upstream author. Which is to be expected as they aren't fixing the software, just the packaging in most cases.
Kernel bugs and issues, also tend to be dealt with upstream, and the usual response is try a later kernel. So it pays if you are a power user (and which Debian users aren't?) to have some idea about kernels if you are messing around with slightly odd hardware.
Strangely, some reports that should go upstream, lurk, and die a slow painful death, and are genuinely difficult to handle, such as the X windows subsystem where bugs are often dependent on hardware choice (amongst many hundreds of graphics cards), seem to get very good bug response. But that might just be gravityboy, and one or two other enthusiastic individuals. Or perhaps it is the nature of those projects to attract individuals who see solving a difficult problem on the desktop of some (comparatively) IT illiterate individual as a challenge.
* I'm guess he must include "PEBCK" in genuine issues?
I filed a LOT of bug reports relating to spelling mistakes in package descriptions, and these are a low priority item, and tend to be fixed when the next release of the package is made.
Currently 71% of the bugs reported under the email address used for the spelling mistakes (and other issues) have been resolved, most of those outstanding are spelling mistakes in minority interest packages. A fair few of the others that are open, probably ought to be closed because they are resolved by later software.
I have to say that the responses have generally been very positives, and helpful. Even to the point, and the BTS/Debian Developers are not there for this, as being classified as "support". Only on one occasion did I disagree with the result, and that was over an issue of ease of use issue with part of the CUPS printer system, I thought it could be made easier with better defaults the maintainer thought the current documentation sufficient.
Like you I was, and still am, a tad nervous about filing bug reports. If something is clearly wrong (spelling mistakes are a good example) then it is an easy call. But where I've upgraded something, and something odd happens, I am always left wondering "did I fiddle too much?".
Almost universally when I've asked Debian Developers about what I consider borderline cases, they all responded file a bug report.
By filing bug reports;
a) You learn how to file better bug reports.
b) Maintainers learn about how the software is used.
c) There is a documented record of issues, and problems, people experience with that package, even if it isn't actually a bug.
The very worst that will happen is it will get closed promptly, and someone you'll likely never meet will think you are an idiot and wasting their time, and promptly forget about you.
One of the authors of a book on how bad software is, claims all(*) bug reports have a genuine issue in them. The issue may not be a classic bug, and often isn't what is reported, but maybe the software is too hard to use, the documentation is wrong, the defaults wrong, or assumptions are made about the kind of person who will try and use the software. Perhaps the software isn't translated completely into another language.
If in doubt file a report. But remember the golden rule, and file the kind of bug report you would want to receive if it was your package. Sometimes this may be just "I updated package X, it now no longer does Y" because you don't know much about the software but are just a regular user, other times it can include the patch to fix it and why you think it appropriate.
I think that wish-list items don't work too well with Debian BTS, except where the maintainer is also the upstream author. Which is to be expected as they aren't fixing the software, just the packaging in most cases.
Kernel bugs and issues, also tend to be dealt with upstream, and the usual response is try a later kernel. So it pays if you are a power user (and which Debian users aren't?) to have some idea about kernels if you are messing around with slightly odd hardware.
Strangely, some reports that should go upstream, lurk, and die a slow painful death, and are genuinely difficult to handle, such as the X windows subsystem where bugs are often dependent on hardware choice (amongst many hundreds of graphics cards), seem to get very good bug response. But that might just be gravityboy, and one or two other enthusiastic individuals. Or perhaps it is the nature of those projects to attract individuals who see solving a difficult problem on the desktop of some (comparatively) IT illiterate individual as a challenge.
* I'm guess he must include "PEBCK" in genuine issues?
[ Parent | Reply to this comment ]
Posted by Anonymous (59.178.xx.xx) on Sun 23 Sep 2007 at 09:22
> Additionally, though I know it's a volunteer movement,
> sometimes it's a bit off putting to submit a bug report
> and nothing happens at all."
I could be wrong here on how polices are applied.
But I think even nothing happening (as in, not even a "won't fix") means
something happens - the package gets orphaned.
PJ
> sometimes it's a bit off putting to submit a bug report
> and nothing happens at all."
I could be wrong here on how polices are applied.
But I think even nothing happening (as in, not even a "won't fix") means
something happens - the package gets orphaned.
PJ
[ Parent | Reply to this comment ]