Submitting Patches

---------------- NEEDS TO BE EXPANDED/REVIEWED ----------------------

Here is a list of things to look for when getting ready to submit a patch to a project, be it ProjectPier core or a contributed project. Following these tips will give your patch a better chance at being reviewed and committed. You can find information about actually creating a patch in the Creating patches section.

Coding style and security

If your code deviates too much from the Coding standards, it will be rejected without further review. You may want to check your code with the code-style.pl helper script to help you find style errors. Well commented/documented code will also be looked upon favorably. Make sure your code follows the security guidelines! Obviously code that introduces security issues will be rejected.

Describe your changes

Describe the details of the change(s) your patch includes and try to be as specific as possible. Note that we prefer technical reasoning above marketing: give clear reasons why "this way" is good. Justify your changes with solid reasoning. It is important to note the version to which this patch applies. To help people test your patch (vs. reviewing the code itself) you should also provide some basic instructions about what problems to look for or specific steps to take to see the effect of the patch in a test site.

Verify your patch

Reviewers are overloaded reviewing and testing patch submissions. Please make their lives easier by assuring the following:

• Your code works! Test your code.
• If your patch is just a quick hack, then don't set your issue to "patch (code needs review)" status, instead set it to "active" or "patch (code needs work)".
• For ProjectPier core, patch against the Trunk. If the patch is accepted into the Trunk it can then be ported back to specific versions. If the patch is for a core bug, you can help speed things along by attaching back-ported versions as separate follow-ups, each one with a version-specific port of your patch. You can only attach a single file to each issue reply. For contributed projects, you should patch against the latest development version (which may or may not be HEAD - check with the project).

Submit your patch

Patches should be submitted via the issue tracker. Create a bug report or feature request, attach your patch using the file upload form. The issue tracker does not accept .zip, .tar.gz or .tgz files so you must attach a patch, not a package of all of your patched files. Set the issue's status to "patch (code needs review)" or "patch (code needs work)". Setting the status to patch is important as it adds the issue to the patch queue.