We're using the SourceForge Patch Manager. Here are the main
- Submit your patch to the patch manager
interface at SourceForge.
You will need to register with SourceForge, and you will need to login
before submitting a patch, or else the 'Submit New'
link will not appear. The patch manager is for
patches only; if you have a problem or suggestion but don't
know how to write the code for it, use the bug manager
- Submit documentation patches the same way. When adding the
patch, be sure to set the "Category" field to
"documentation". For documentation errors without patches,
please use the bugs manager instead.
- We like unified diffs. We grudgingly accept contextual diffs.
Straight ("ed-style") diffs are right out! If you don't know
how to generate context diffs, you're probably not qualified to
produce high-quality patches anyway <0.5 wink>.
- Please use forward diffs. That is, use "diff -u oldfile
newfile", and not the other way around.
- If you send diffs for multiple files, concatenate all the diffs in
a single text file. Please don't produce a zip file with multiple
- We appreciate it if you send patches relative to the current svn tree. These are our
latest sources. Even a patch relative to the latest alpha or beta
release may be way out of date.
- Please add a succinct message to your SourceForge entry that
explains what the patch is about that we can use directly as a checkin
message. Ideally, such a message explains the problem and describes
the fix in a few lines.
- For patches that add or change functionality: please also update
the documentation and the testcases (the Lib/test
subdirectory). For new modules, we appreciate a new test module
(typically test/test_spam.py). In this case, there's no need to mail
the documentation to a different address (in fact, in order to verify
that the bundle is complete, it's easier to mail everything together).
- There are a variety of additional style requirements.
Please have a look at these before writing new code. Also have a look at
PEP 8: Python Style Guide.