AW: [mythtv] Bug and feature asking

Jochen Kühner jochen.kuehner at gmx.de
Thu Sep 15 10:38:09 UTC 2005


In the wiki is also a list of asked features.
This is also ported t the new wiki:

http://www.mythtv.org/wiki/

-----Ursprüngliche Nachricht-----
Von: mythtv-dev-bounces at mythtv.org [mailto:mythtv-dev-bounces at mythtv.org] Im
Auftrag von Michael T. Dean
Gesendet: Mittwoch, 14. September 2005 18:38
An: Development of mythtv
Betreff: Re: [mythtv] Bug and feature asking

On 09/14/05 07:20, Mattia Martinello wrote:

> Where I can post a bug and a feature asking for MythTV?

(Developers, please correct me if I'm wrong about any of the following, 
and I hope I'm not overstepping my bounds in posting this.)

Please do not stop reading after the next sentance...

If you *know for sure* it's a bug and that it still exists in the SVN 
version of Myth, you can post it at the SVN Trac Server ( 
http://svn.mythtv.org/ ).  *However*, note that a great deal of the bugs 
posted there are not actually bugs--but instead are mistaken for bugs by 
users who don't understand how the features are meant to be used.  In 
these cases posting the bug to Trac is actually detrimental to the 
development process.

No.  I'm not saying, "It's not a bug; it's a feature."  If you browse 
the list of issues posted to Trac, you'll notice a great deal of these 
"bugs" are marked invalid.  Often, a lot of developer time is wasted 
marking these mistaken bug reports as invalid (often with a short 
description of why)--and even more time is wasted answering the 
follow-up questions on Trac posed by the people reporting the invalid 
bug when they failed to understand the short description given when 
marked invalid.  Since, for the most part, only the developers are 
tracking the issues in Trac, the follow-up questions on Trac must be 
answered by developers, which means that they're wasting time they could 
be using to write code.  Also, when posting to Trac instead of the 
lists, none of the rest of the users of Myth get an opportunity to 
contribute by answering the questions.

Also it is critical to verify that the bug still exists in the current 
development version before posting a bug report.  Many of the bugs 
reported on Trac that are, in fact, bugs, are duplicates (posted 
multiple times) or are reports of bugs that were previously fixed (and 
no longer exist in the development version).  Both types of reports 
waste developer time.

Therefore, the best approach--especially if you're not intimately 
familiar with MythTV's internals--is to post to the user's mailing list 
a question regarding the behavior you're seeing and your reasoning for 
why it may be a bug.  This allows others to verify that it a) is a bug, 
b) still exists in the development version, and c) is not a duplicate of 
an already-reported bug.  Also, it allows users (as opposed to only 
developers) to explain the behavior you're seeing if it's not a bug and, 
in most cases, to recommend the proper way to get the behavior you 
desire using the other features of Myth.  If you post to the Trac server 
first, you're denying users (non-developers) an opportunity to get 
involved.  And, more importantly, on the lists, you'll typically get 
much longer, more descriptive answers than you'll see on Trac (the 
developers don't want to waste a lot of time on long complicated 
explanations of why something is not a bug).  Note, also, that the 
developers keep on top of even the user's list, so you're as likely to 
make the issue known to developers by discussing it on the user's list 
as on the developer's list or even on Trac.

If, once the issue has been discussed on the mailing list, it's 
determined to be a bug, you may be asked to post the issue on Trac 
(often with information required for debugging).  In many cases, 
however, simply making the issue known on the lists results in a fix or 
enhancement.  See below for an example.

If you've found a bug, and you're sure it's a bug, and you have written 
a patch for the bug against the current SVN version, you should post 
that patch to Trac.  Note, though, that by first asking on the lists, 
you may save yourself the time required to write the patch when you find 
out that it's not a bug, but a misunderstanding of the purpose of the 
feature or a lack of knowledge of some other feature that provides the 
behavior you're seeking.  Also, in some cases, you might find someone 
else is already working on a patch for that issue and can either let 
them finish it or volunteer to help.  This way, if you're not wasting 
time writing unnecessary patches, you can spend the time you would have 
wasted writing those patches to write a patch that /will/ be added to 
Myth and that others can enjoy.

As far as features go, it's *always* best to post feature requests on 
the user's mailing list.  This allows a large group of people to see 
your suggestion and a) recommend the proper way of accomplishing the 
task, b) discuss possible additional functionality you may not have 
considered (to make your suggestion even better), and c) assuming 
someone likes the suggestion--volunteer to write (or help you write) the 
code.  Also, in many cases, you'll find that your suggestion may not 
scale to all the possible uses of MythTV (i.e. from standard-definition 
TV to high-definition TV, from single combined frontend/backend to a 
single backend with multiple frontends, or multiple backends and 
frontends, etc...).  In those cases, others may be able to provide 
additional information that makes your suggestion more scalable.

Note that posting an "enhancement" to Trac will be far less effective 
(will probably be marked invalid if posted without a patch), as the 
"enhancement" on Trac is not a "request for enhancement."  Requests for 
enhancement should be discussed on the list, as mentioned above.

And, finally, thank you for taking time to ask how to report a bug, 
Mattia.  I, for one, sincerely appreciate your willingness to spend a 
little of your own time to make sure you don't waste the developers' 
time.  (And, I'm sure that everyone who uses the features created during 
the developers' time you've saved will appreciate it, too--even if they 
don't know it.)

Mike (not one of the developers, but someone who's been watching Myth 
development for quite some time)


_How Open Source Development Is Supposed to Work_

Note, also, that even taking this approach and posting to the lists, a 
developer may decide to make changes based on your question.  For 
example, I have posted questions/feature requests on the user's list and 
received answers explaining how to properly accomplish the task I'm 
trying to accomplish with the features currently available in Myth and 
later the developers have added functionality similar to what I suggested.

One example:
 - My post ( 
http://www.gossamer-threads.com/lists/mythtv/users/144952#144952 ) 
talking about the math I had to do to skip to X minutes before the end 
of a recording
 - Which was inspired by those above it in the thread, and especially 
Ian's post ( 
http://www.gossamer-threads.com/lists/mythtv/users/144857#144857 -- the 
one I quoted)
 - Which was folowed by Bruce Markey's answer to my post, explaining 
that I could accomplish the task using a much easier process ( 
http://www.gossamer-threads.com/lists/mythtv/users/144958#144958 )
 - Followed by the change that incorporated the feature I 
mentioned--only 4 days after my post ( 
http://cvs.mythtv.org/trac/changeset/7090 )
 - And an additional change Bruce thought of while explaining how to 
accomplish the task I was trying to accomplish ( 
http://cvs.mythtv.org/trac/changeset/7097 )

This provides an excellent example of why the exchange of ideas on the 
list is the best way build a great PVR.  :)



More information about the mythtv-dev mailing list