[mythtv-users] How to make a good bug report?

Bruce Markey bjm at lvcm.com
Fri Jul 9 17:30:52 EDT 2004


Joseph A. Caputo wrote:
...
> ...but you didn't provide that information the first time.  In reporting 
> *any* bug for *any* software, you should at least include:
> 
> - specific hardware information
> - specific OS version information
> - specific software version information

I appreciate your diligence and intent and understand what you
are suggesting and why. However, I whole-heartedly disagree with
the statement above. A wide range of info may be helpful to start
researching a support question but a bug report should have the
exact conditions when the bug occurs and no misleading or irrelevant
info.

What is needed in a bug report is enough information for someone
else using another system to observe the same mis-behavior. A bug
report is "If you do this under these conditions, this will happen".

"I'm seeing something weird and I don't know why" is a user support
question. It may become a bug report eventually if it can be narrowed
down to "do this and this will happen".

If there is a bug in MythTV source code, it will most likely happen
on all hardware, Linux distributions, and supported versions of
other prerequisite software packages.

If a problem happens in one situation but not another, then that
needs to be spelled out. For example, a problem may exist while
playing back files that were hardware encoded but may not if software
encoded. In that case, it is important to point out the hardware
in order to "observe the same mis-behavior".

Realize that in cases where there is different behavior with
different Linux distributions, other software or hardware, the
problem or bug may be in the other software, hardware, drivers,
or config. For a bug against the mythtv code base, there may need
to be more information about why this is a bug in the myth code
and/or why there should be or needs to be a workaround for the
shortcomings of the the other thing.

While it is easy to believe that the reporter padding a bug report
with a lot of irrelevant info shows diligence, the color of the case
or the length of the ethernet cable is rarely the issue.

As for the responders, I've seen a game played time and time again
on lots of projects, in customer support groups in companies and,
yes, even on this list ;-). Someone who expects to be perceived as
an expert and doesn't know the answer will ask for a gift basket
full of system information. They are really hoping to find something
that they can pin the blame on so rather than saying "I don't know"
(because they don't know =) they can say "Oh, it must be because you
are using this". This is rarely productive and always disheartening
to see someone trying to fix their system being asked for a laundry
list of information by someone who I know will never solve the
problem.

Now, as for bug 25, the conclusion of "If you do this under these
conditions, this will happen" is "4. Observe flickering". The correct
closure of this is WORKSFORME. If Isaac or I or almost anyone
follows his steps we do not "observe flickering" and therefore
there is no bug that can be fixed.

However, Isaac's first closure will probably turn out to be more
correct as INVALID. There is no code in the mythtv source base
that tells everyone's EPG to flicker. The problem is almost surely
a problem with the video card, it's driver, X11, window manager,
Qt installation, poor signal quality, bitrate that overruns the
system capacities, etc. It may be a bug with another project but
more likely is a support question for another project or product
and is not a bug in myth code.

--  bjm


More information about the mythtv-users mailing list