Difference between revisions of "Submitting Bug Fixes"
m (Replaced 0.21 with {{CurrentRelease}}) |
("SVN" is not a version. "Myth" != "MythTV". Link to UsingGit for Git usage info rather than trying to duplicate it here.) |
||
| Line 5: | Line 5: | ||
== 1. Join the dev community == | == 1. Join the dev community == | ||
| − | If you're thinking about submitting code to | + | If you're thinking about submitting code to MythTV, you want to subscribe to the [http://www.mythtv.org/mailman/listinfo/mythtv-dev/ mythtv-dev mailing list]. This is where discussion about patches, new features, and bugs goes on. You can also use the [http://gossamer-threads.com/lists/mythtv/dev/ searchable archives] to find out what's been going on lately. |
| − | == 2. Run the current | + | == 2. Run the current unstable/development version == |
| − | Its best to submit patches based on the latest version of MythTV | + | Its best to submit patches based on the latest unstable/development version of MythTV. This is because code changes significantly during development and the patch may no longer be relevant with current code. |
| − | Before you install the | + | Before you install the unstable/development version, please get the latest release ({{CurrentRelease}}) 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 | + | Once you're comfortable with the release version, you can get started with MythTV unstable/development version. |
== 3. Develop your patch == | == 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! | + | 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! See the [http://code.mythtv.org/trac/wiki/UsingGit MythTV Using Git] page for information on development with Git. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== 4. Submit your patch == | == 4. Submit your patch == | ||
| − | Next, you need to make a ticket on Trac and attach your patch. See [http:// | + | Next, you need to make a ticket on Trac and attach your patch. See the [http://code.mythtv.org/trac/wiki/TicketHowTo Ticket Howto] for instructions. |
== 5. Be patient == | == 5. Be patient == | ||
| − | This can be the hardest part of the process. You want your patch to be in | + | This can be the hardest part of the process. You want your patch to be in an official release for all to see, but first it has to be checked by others and deemed appropriate by one of the developers with commit privileges, then accepted and tested in the unstable/development code. The devs try to look at patches at least once a week, but sometimes they're busy and it can take 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. | 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. | ||
| Line 38: | Line 31: | ||
== 6. After it's committed == | == 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 | + | 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 MythTV in the future, you should still keep an eye on things. Sometimes bugs aren't found until after the code is in wide testing in the unstable/development version; 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 MythTV. |
| − | Being a part of the | + | Being a part of the MythTV 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. |
[[Category:Developer Documentation]] | [[Category:Developer Documentation]] | ||
[[Category:HOWTO]] | [[Category:HOWTO]] | ||
Latest revision as of 22:14, 26 December 2010
Contents
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 MythTV, 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 unstable/development version
Its best to submit patches based on the latest unstable/development version of MythTV. This is because code changes significantly during development and the patch may no longer be relevant with current code.
Before you install the unstable/development version, please get the latest release (34.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 MythTV unstable/development version.
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! See the MythTV Using Git page for information on development with Git.
4. Submit your patch
Next, you need to make a ticket on Trac and attach your patch. See the Ticket Howto for instructions.
5. Be patient
This can be the hardest part of the process. You want your patch to be in an official release for all to see, but first it has to be checked by others and deemed appropriate by one of the developers with commit privileges, then accepted and tested in the unstable/development code. The devs try to look at patches at least once a week, but sometimes they're busy and it can take 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 MythTV in the future, you should still keep an eye on things. Sometimes bugs aren't found until after the code is in wide testing in the unstable/development version; 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 MythTV.
Being a part of the MythTV 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.
