Check-in Policies

Write access to the Python SVN tree is not automatically granted, though there's no formal process to go through to get it. If the python-dev team knows who you are, whether through mailing list discussion, having submitted patches, or some other interaction, then you can ask for full SVN access. You'll need to have an SSH key, and provide it with your request.

If you're granted SVN write access, you have to follow a few simple rules.

• Use the patch manager to submit your first two or three patches for review before you commit, unless specifically instructed otherwise.

• Before making a code change, make sure you've checked out the most current version.

• Before checking in a code change, re-run the entire Python test suite to be sure that you haven't broken anything. To run the complete test suite, use the following command from the top directory of the source tree:

  ./python ./Lib/test/testall.py
  

  If the module you're modifying doesn't have a test suite, you could consider writing a set of test cases for it.

• When fixing a bug, you should add a test case to the test suite located in Lib/test/ that would have caught this bug. When adding a whole new class or module, you should add a set of tests for it.

• If a change affects OS-dependent behavior, run your tests on as many OSes as you have easy access to. For additional testing, see the Python Testers page.

• When a patch changes behavior or fixes a noteworthy bug, you should add an entry to the Misc/NEWS file about the change. The file is divided into sections for the core and built-ins, extension modules, the standard library, and accompanying tools, and a change should be described in the appropriate section. You don't need to update the "What's New in Python" document in Doc/whatsnew.

• Simple or trivial fixes can be just checked in. This is especially true if it's for code or documentation that you own, but you can make a change to another person's module; code ownership is not particularly strict on the Python project. Just be very sure that your fix is correct and doesn't introduce any incompatibilities.

• When in doubt, don't commit changes. If you're not sure a patch is bug-free, or are in doubt about the approach it takes, don't check in the patch and trust that it'll all get sorted out eventually. Instead, create a patch in the patch tracker (see below) and discuss the patch with the other developers until everyone agrees it's correct.

• The previous rule applies even more strongly to large patches that touch many files or make far-reaching changes. The Python source tree is managed for stability, meaning that if you make a checkout at a random point in time the tree will almost always compile and be quite stable. Large sets of changes, such as the 2.2 type/class rewrite, are usually tested on a branch first and merged into the main stream of development once they're believed to be complete.

• Before new releases, code freezes will be announced on python-dev. Obey them and don't make checkins without getting approval on the python-dev list first.