What NOT To Do <ul><li>Submit the patch privately directly to the maintainer *
Submit a compressed patch using gzip or similar tools
Submit a patch without a clear explanation of what it does and why
Use language that could be interpreted as being critical of the project, its code, or its members </li></ul>* Possible exceptions may include critical security bugs or if the project's contribution instructions explicitly ask you to submit patches to individuals
Making Your Patch a Slam-dunk: Follow the project's coding style <ul><li>Use the same whitespace style (tabs vs. spaces) that the surrounding code uses
Use the same format for commit logs (git-based projects tend to be especially strict about this)
Keep your commits atomic and logically separated </li></ul>
Making Your Patch a Slam-dunk: Tie it to a bug number <ul><li>Find the project's bugtracker </li><ul><li>Search for the bug
If it doesn't exist, file a new bug </li></ul><li>Some projects, e.g. Mozilla, do not accept any code unless it is associated with a bug filed in Bugzilla </li></ul>
Making Your Patch a Slam-dunk: Mention how it has been tested <ul><li>From the maintainer's perspective, it is natural to be cautious when accepting patches from new contributors who may not know the codebase well.
Testing your code shows not only that your patch doesn't break anything, but that you're disciplined enough to test your code as a matter of routine.
“ This patch has been tested on the Yocto Project's autobuilder and works for all of our architectures: x86/x86-64/arm/mips/ppc” </li></ul>
Making Your Patch a Slam-dunk: Include documentation patches <ul><li>This is more true for feature additions than bugfixes
Keeping documentation up to date is one of the more challenging and thankless jobs a maintainer has to do
By including documentation patches, you will stand out above most other contributors as being detail-oriented and helpful </li></ul>
Dealing with Rejection Sometimes your patch will be rejected. It is important to make sure you understand whether the rejection is due to fundamental differences in philosophy, or whether the patch might be accepted if it were re-worked according to the preferences of the maintainer. If it's the former case, remain polite and accept it. Explain that we will continue to maintain the patch and are open to future collaboration.
The maintainer may want the patch re-worked to meet project requirements. This is acceptable, and the work should be done and the patch re-submitted. Remember, every patch we get upstream means we no longer have to maintain it . This saves us more work in the long run. It's also part of being a good citizen in open source communities! Dealing with Rejection
Common Patch Submission Workflow with Git <ul><li>Clone the upstream git repo, make changes in your own branch and commit them
git format-patch -N (where N is the number of commits to include in the patchset)
Patch file(s) will be generated in the current directory. Use them as input to git send-email :