================= Development Tools ================= SVN Tree ======== The Python source code is stored in the Subversion, or SVN, version control system. Anyone can check out a read-only copy of the source tree by using anonymous SVN. To check out the tree:: svn co http://svn.python.org/projects/python/trunk python Running ``svn update`` will update the tree to the most recent version. Checkin messages and the accompanying diffs are sent to the `python-checkins `_ mailing list so that they can be read and double-checked by the other developers. If you've been granted write access to the source tree, it's strongly recommended that you subscribe to this list. For information about SVN, see "Version Control with Subversion" at http://svnbook.red-bean.com/. Check-in Policies ----------------- There's no formal process to gain write access to the Python SVN tree. If the python-dev team knows who you are, whether through mailing list discussion, having submitted patches, or some other interaction, then you may ask for full SVN access and have a reasonable chance of being accepted. You'll need to have an SSH key and include 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, always 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/regrtest.py or just ``make test`` on operating systems that have the ``make`` command. * 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 the module you're modifying doesn't have a test suite, create one, even if it only includes a single test that exercises the change you're making. Consider writing a larger set of test cases for the module. * 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. Optionally you can add a note about the change to the "What's New in Python" document in ``Doc/whatsnew/``; see the comments at the top of that file for instructions. * 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 correct or are uncertain about the approach it takes, don't apply 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. Bug Tracking ============ To report a bug in Python, use `the issue tracker `_. Don't report bugs by posting them to a mailing list or by sending them to a particular developer as a private e-mail; most likely the bug will end up buried under later postings and e-mails and subsequently forgotten. Once a problem is recorded in the bug tracker, though, it won't get lost. It may sit unchanged for a while until someone gets around to looking at it, but before releases someone will go over the outstanding bugs and fix or close them. PEP 3, `"Guidelines for Handling Bug Reports" `_ explains the procedures for handling bugs once they've been reported. Patch Tracking ============== Just like bugs, and for much the same reasons, patches should be submitted to the `issue tracker `_, and not posted to python-dev or e-mailed to people. Often a patch will need some modification before final acceptance, so be prepared for a few iterations before the patch is ready to be checked in. For conventions that should be followed when preparing a patch, see the :ref:`patch-guidelines`. URL Redirectors =============== The canonical URL of a bug report is http://bugs.python.org/issue1010 This would be the link for bug #1010. A slightly shorter form is available through a redirect, as simply http://bugs.python.org/1010 From the time when the issues where tracked at SourceForge, another redirector is available at http://www.python.org/sf/1010 The old URLs using the SF redirector continue to work; URLs that point at sf.net directly are no longer valid.