How to Make a Patch for an Open Source Project
One of the greatest advantages of open source is the ability to view and modify the source code. For programmers, this means diagnosing and fixing problems themselves instead of waiting for someone else to do it. In order to contribute this fix to the developers of the open source project, you need to send them a patch.
Other People Are Reading
Things You'll Need
- Software source code
- Code management software (CVS or SVN)
- Internet connection
- Diff program
Instructions
-
Make a Patch for an Open Source Project
-
1
Identify a problem or bug in a piece of open source software. This usually occurs as you're using the software. The program either crashes or behaves in an unexpected or unintended manner. Sometimes it's a matter of being able to visualize a better way of accomplishing something.
-
2
Download the source code. Since you're going to make a patch to send to the developers, you need the original code to write it. This is done with source code management software like Concurrent Versions System (CVS) or Subversion (SVN).
-
-
3
Go to the software's project page and click on "Code" if the developer is using CVS on SourceForge. Follow the directions for anonymous CVS access. This will allow you to download the developer source code from CVS.
-
4
Search the developer's website for instructions to download the source code if he is using a service other than SourceForge. If the instructions are not on the website, you will need to email the developer or a related mailing list for assistance.
-
5
Diagnose the problem without making any modifications. Now that you have the source code, you can find out where the software is breaking.
-
6
Copy every file you're going to modify to a temporary .old.* file. For example, if you were going to change "eval.c," you would copy "eval.c" to "eval.old.c." This keeps a record of the old file so the
diffprogram has something to work from. -
7
Get coding and fix the problem. It could be as simple as one-line fix, such as changing a function parameter or adding some parentheses to some arithmetic, or much more complicated. Sometimes you may need to rewrite an entire function.
-
8
Clean up your work to make the developer's job easier. Clean up any junk lines or comments you may have left while fixing the code and make sure your indentation and whitespace style is the same as the developer's. You should also be sure that you followed any naming conventions the developer used if you want your patch to be submitted. Not doing the cleanup means the developer may not have time to clean up your code and your patch will never be accepted.
-
9
Run the
diffprogram. Thediffprogram compares two files and records the differences between them. This will generate the patch, so later the patch program can add these changes to the developer's source code. For every file you modified, you need to run thediffprogram like this:"patch -uN eval.old.c eval.c > eval.patch" -
10
Send the patch to the developer, emailing it to him in an attachment. The developer can download source from CVS, apply the patch and commit the changes. He will probably also add you to the credits if the software has any (usually located in the readme file).
-
1
Tips & Warnings
Development source code is different than the release source code. The release source code is in a known good state, but the development source code is changed as the developers are working on it. Be aware that since the source code is in an unknown state when you download the development source code, it may not even compile.
More Like This
Comments
-
Stanislaw Smetanin
Aug 14, 2010
Please, fix a blunder in the step nine, instead of patch contributor must use a diff utility: "diff -uN eval.old.c eval.c > eval.patch" -
cybershadow
Feb 23, 2009
This how-to is wrong in several places. Points 3 and 4 should be a subpoint of point 2, as it's just a clarification (more of a nitpick). You do not need to make .old copies if you use source control, because "svn diff" and CVS's equivalent will generate a patch of all your edits. Often it's hard to "diagnose" a problem without modifying the source code - people often add/enable logging and other debugging code. Modern versions of the diff program allow comparing directories, which means that for non-SCM source distributions you can just back up the entire source folder, and not bother making .old files for everything you edit.
-
cybershadow
Feb 23, 2009
This how-to is wrong in several places. Points 3 and 4 should be a subpoint of point 2, as it's just a clarification (more of a nitpick). You do not need to make .old copies if you use source control, because "svn diff" and CVS's equivalent will generate a patch of all your edits. Often it's hard to "diagnose" a problem without modifying the source code - people often add/enable logging and other debugging code. Modern versions of the diff program allow comparing directories, which means that for non-SCM source distributions you can just back up the entire source folder, and not bother making .old files for everything you edit.
