Submitting Bug Fixes

From MythTV Official Wiki
Revision as of 12:08, 16 November 2010 by Pelago (Talk | contribs)

Jump to: navigation, search

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

The MythTvDevelopmentHowTo has several important pointers, including Coding Standards so that your code isn't rejected for trivial reasons. Remember, change all tabs to 4 spaces!

Once the code is ready, create the patch from the root of the MythTV SVN tree:

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 svn diff.

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.