Submitting Patches
Make sure you have checked out trunk and made your modifications to the latest revision in trunk. A patch submission should contain one logical change; please don't mix N unrelated changes in one submission — send N separate emails instead.
The patch itself should be in unified diff format. Create a patch and attach it to the ticket for inclusion into trunk.
svn diff path/to/modified/file.php > file.php.diff
It is normal for patches to undergo several rounds of feedback and change before being applied. Don't be discouraged if your patch is not accepted immediately — it doesn't mean you goofed, it just means that there are a lot of eyes looking at every code submission, and it's a rare patch that doesn't have at least a little room for improvement. After reading people's responses to your patch, make the appropriate changes and resubmit, wait for the next round of feedback, and lather, rinse, repeat, until some committer applies it.
If you don't get a response for a while, and don't see the patch applied, it may just mean that people are really busy. Go ahead and repost, and don't hesitate to point out that you're still waiting for a response. One way to think of it is that patch management is highly parallizable, and we need you to shoulder your share of the management as well as the coding. Every patch needs someone to shepherd it through the process, and the person best qualified to do that is the original submitter.
