Submitting Bug Fixes
Submitting Patches to MythTV
To submit your patches to MythTV you need to follow the process below. Not following this guide might mean that your patches will be delayed, rejected or ignored.
1. Join the dev community
If you're thinking about submitting code to Myth, you want to subscribe to the mythtv-dev mailing list. This is where discussion about patches, new features, and bugs goes on. You can also use the searchable archives to find out what's been going on lately.
2. Run the current SVN version
Its best to submit patches based on the latest version of MythTV (SVN trunk). This because the developers might not have the time to merge your patches based on older versions.
Before you install the SVN version, please get the latest release (29.0) compiling and running first. This is the only way to be sure that your configuration is correct, otherwise you'll be fighting with a less stable source tree and your own machine at the same time.
Once you're comfortable with the release version, you can get started with Myth SVN. You may find more help on the Development Wiki.
3. Develop your patch
svn diff libs/libmythtv/changed_file.cpp [...]
Please submit one diff per feature or bugfix. Don't make a diff for every file, and don't mix separate features into the same patch. For new files, you can use
svn add *newfile* before running
4. Submit your patch
Next, you need to make a ticket on Trac and attach your patch. See Ticket Howto for instructions.
5. Be patient
This can be the hardest part of the process. You want your patch to be in SVN for all to see, but first it has to be checked by others and deemed appropriate by one of the developers with commit privileges. The devs try to look at patches at least once a week, but sometimes they're busy and it can take a while. A gentle reminder to the list can be OK if your patch has been ignored for a while.
If someone on the list asks a question or poses an alternate solution for part of your patch, be proactive and respond. If you can resubmit a patch that addresses their concerns, it will greatly increase your chances of having the patch accepted. If you don't adapt your patch or defend your original reasoning, then your patch will likely be abandoned. The process isn't done when you post your ticket; you have to see it through the commit process.
6. After it's committed
Okay, you've updated your patch due to mythtv-dev feedback, and it gets committed. Now you can relax, right? Nope! If you want to work on Myth in the future, you should still keep an eye on things. Sometimes bugs aren't found until after the code is in SVN; monitor the -dev and -users lists to see if your code causes any problems. Also, you should be prepared to maintain your new feature through code upgrades. Nobody wants to get stuck maintaining the code you wrote. The best way to make friends is to stick with your code and offer patches when it can take advantage of other advances in Myth.
Being a part of the Myth developers community can be a very rewarding experience, if you keep these things in mind. By knowing the process, you and the other developers can spend less time on trivial matters and more time on improving MythTV.