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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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. :) _______________________________________________ mythtv-dev mailing list mythtv-dev@mythtv.org http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
