Python @ SourceForge - Frequently Asked Questions

To get the real name, click on "View members" in the "Developer Info" field, then click on the user name you're unsure about.
A recent [2001-04-29] list of mapping is given here:

akuchling	A.M. Kuchling
bwarsaw	Barry Warsaw
cgw	Charles G. Waldman
david_ascher	David Ascher
dcjim	Jim Fulton
effbot	Fredrik Lundh
esr	Eric S. Raymond
fdrake	Fred L. Drake, Jr.
gstein	Greg Stein
gvanrossum	Guido van Rossum
gvwilson	Greg Wilson
gward	Greg Ward
jackjansen	Jack Jansen
jhylton	Jeremy Hylton
klm	Ken Manheimer
larsga	Lars Marius Garshol
lemburg	M.-A. Lemburg
loewis	Martin v. Löwis
mhammond	Mark Hammond
montanaro	Skip Montanaro
moshez	Moshe Zadka
nascheme	Neil Schemenauer
nowonder	Peter Schneider-Kamp
ping	Ka-Ping Yee
prescod	Paul Prescod
purcell	Steve Purcell
sjoerd	Sjoerd Mullender
theller	Thomas Heller
tim_one	Tim Peters
tismer	Christian Tismer
tmick	Trent Mick
twouters	Thomas Wouters

2. CVS

2.1.:

Q: How do I browse the CVS tree online?

A:

If you don't have CVS or you don't want to download the source tree, you can browse it using viewcvs at:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/

2.2.:

Q: How do I check out a CVS version of Python?

A:

If you are not a SourceForge-recognized Python developer you can still check out an anonymous CVS version (read-only) of Python:

export CVSROOT=:pserver:anonymous@cvs.python.sourceforge.net:/cvsroot/python
cvs login
cvs -z3 co python

If you are indeed a developer you can check out a read/write version with ssh:

export CVS_RSH=ssh
export CVSROOT=sf_username@cvs.python.sourceforge.net:/cvsroot/python
cvs -z3 co python

2.3.:

Q: What setting should I use?

A:

That is, of course, hard to answer in the general case. I use the following .cvsrc file:

diff -c
update -d

This defaults diff to context diffs (almost a requirement as everything else is harder to read) and tells update to automatically checkout new subdirectories.

2.4.:

Q: I get the following error message:

Sorry, you don't have read/write access to the history file /cvsroot/python/CVSROOT/history
Permission denied

A:

If you are not a developer, you don't have read/write access. You have to check out an anonymous copy. If you are a developer you have to be in the SourceForge group "python". You can check this with the following commands:

ssh -l sf_username shell.sourceforge.net
groups

If you have just recently (< 6 hours) been added to the Python project, you probably have to wait for the SourceForge servers to synch up. This can take up to 6 hours.

2.5.:

Q: Where can I learn more about CVS?

A:

For SourceForge specific information consult their CVS documentation at

http://sfdocs.sourceforge.net/sfdocs

For general (and more advanced) information consult the free CVS Book at

http://cvsbook.red-bean.com/cvsbook.html#Introduction

2.6.:

Q: How can I remove a directory from the CVS tree?

A:

Simple answer: You cannot!
More complicated answer: Remove all files from the directory, delete the directory, use the -P (prune) option of the update command:

cd the_directory
rm file1 file2 file3
cvs remove file1 file2 file3
cvs ci -m "removed all files" file1 file2 file3
cd ..
cvs update -P

2.7.:

Q: How to revert changes?

A:

The fast (and history-friendly) method for backing out a CVS commit is the use of the join flag of the update command. You supply the last version you committed (and probably messed up) with the first and the version you want to back out to with the second flag. Example given:

cvs update -j 1.17 -j 1.16 ceval.c
cvs update
cvs commit ceval.c

This example would create and apply a reverse patch from revision 1.17 to revision 1.16 of ceval.c.

2.8.:

Q: How to add binary files?

A:

You probably want to turn off keyword expansion and line-ending conversion:

cvs add -kb newfile.bin
cvs commit newfile.bin

2.9.:

Q: How to force a branch tag on a file?

A:

The quickest way to force a branch tag branch_tag on a file is to issue the command

cvs tag -F -b -r revision branch_tag file

for each file, where revision is the revision where the tag should be and file is the file. Note that -F means force (otherwise you get a complaint because the tag is already defined) and -b means branch which makes the tag a branch tag.

3. Patches

3.1.:

Q: How to make a patch?

A:

If you are using CVS (anonymous or developer) you can use CVS to make the patches for you. Just edit your local copy and enter the following command:

cvs diff -c | tee ~/name_of_the_patch.diff

Else you can use the diff util which comes with most operating systems (a Windows version is available as part of the cygwin tools).

3.2.:

Q: How to submit a patch?

A:

Please read the Patch Submission Guidelines at

http://www.python.org/patches

A recent copy can be found in the Appendix of this FAQ.

3.3.:

Q: How to change the status of a patch?

A:

To change the status of a patch or assign it to somebody else you have to be a) a SourceForge-recognized Python developer and b) a patch administrator. Unfortunately the SourceForge default for developers is not to be patch administrators. Contact one of the project administrators if the following does not work for you.

Click on the patch itself. In the screen that comes up, there is a drop-box for "Assigned To:" and a drop-box for "Status:" where you can select a new responsible developer or a new status respectively. After selecting the appropriate victim and status, hit the "Submit Changes" button at the bottom of the page.

Note: If you are sure that you have the right permissions and a drop-box does not appear, check that you are actually logged in to SourceForge!

For more information about the use of the "Status:" and "Assigned To:" fields consult the Patch Manager Guidelines. A recent copy can be found in the Appendix of this FAQ.

4. Windows

4.1.:

Q: How to install cvs and ssh

A:

Here's a link to text instructions for setting up a cmdline CVS using SSH under Windows, originally developed by Andy Robinson. Tim Peters is too lazy to change it into HTML every time it's updated. All the Windows folks at Reportlab and PythonLabs swear by this scheme -- and all the others we've tried are broken.

5. Macintosh

5.1.:

Q: How to use cvs over ssh?

A:

As far as we know it is currently quite impossible to use cvs over ssh.
Any reports of getting it to work and/or pointers to more info would be appreciated!

6. Bugs

6.1.:

Q: Where can I submit/view bugs for Python?

A:

The Python project uses SourceForge's bug tracking facility. Go to http://sourceforge.net/bugs/?group_id=5470 for all bug management needs. You will need to create a SourceForge account for yourself before submitting the first bug report; anonymous reports have been disabled since it was too difficult to get in contact with submitters.

6.2.:

Q: How do I use the sourceforge bug manager?

A:

By default, you will see the list of all Open bugs. You can change which bugs you're viewing by selecting the assigned_to/status/area/type select boxes.

To submit a bug, use the "Submit a Bug" link, near the top of the page.

A. Appendix

A.1.: Patch Manager Guidelines

Intended use of SourceForge patch Resolution, Status & "Assigned To" fields

Revision 4
16-Mar-2001

In general, the Resolution and Status fields should be close to self-explanatory, and the "Assigned to:" field should be the person responsible for taking the next step in the patch process. Both fields are expected to change value over the life of a patch; the normal workflow is detailed below.

When you've got the time and the ability, feel free to move any patch that catches your eye along, whether or not it's been assigned to you. And if you're assigned to a patch but aren't going to take reasonably quick action (for whatever reason), please assign it to someone else ASAP: at those times you can't actively help, actively get out of the way.

If you're an expert in some area and know that a patch in that area is both needed and non-controversial, just commit your changes directly -- no need then to get the patch mechanism involved in it.

You should add a comment to every patch assigned to you at least once a week, if only to say that you realize it's still on your plate. This rule is meant to force your attention periodically: patches get harder & harder to deal with the longer they sit.

Status Open, Resolution None

The initial state of all patches.
The patch is under consideration, but has not been reviewed yet, or is under review but not yet Accepted or Rejected.
The Resolution will normally change to Accepted or Rejected next.
The person submitting the patch should (if they can) assign it to the person they most want to review it.
Else the patch will be assigned via [xxx a list of expertise areas should be developed] [xxx but since this hasn't happened and volunteers are too few, random assignment is better than nothing: if you're a Python developer, expect to get assigned out of the blue!]
Discussion of major patches is carried out on the Python-Dev mailing list. For simple patches, the SourceForge comment mechanism should be sufficient. [xxx an email gateway would be great, ditto Ping's Roundup]
For the reviewer: If you're certain the patch should be applied, change the Resolution to Accepted and assign it back to the submitter (if possible) for checkin. If you're certain the patch should never be accepted, change the Resolution to Rejected, Status to Closed, and assign it to None. If you have specific complaints that would cause you to change your mind, explain them clearly in a comment, leave the status Open, and reassign back to the submitter. If you're uncertain, leave the status Open, explain your uncertainies in a comment, and reassign the patch to someone you believe can address your remaining questions; or leave the status Open and bring it up on Python-Dev.

Status Open, Resolution Accepted

The powers that be accepted the patch, but it hasn't been applied yet. [xxx flesh out -- Guido Bottleneck avoidable here?]
The Status will normally change to Closed next.
The person changing the Resolution to Accepted should, at the same time, assign the patch to whoever they believe is most likely to be able & willing to apply it (the submitter if possible).

Status Closed, Resolution Accepted

The patch has been accepted and applied.
The previous Resolution was Accepted, or possibly None if the submitter was Guido (or moral equivalent in some particular area of expertise).

Status Closed, Resolution Rejected

The patch has been reviewed and rejected.
There are generally no transitions out of this state: the patch is dead.
The person setting this state should also assign the patch to None.

Status Open, Resolution Out of date

Previous Resolution was Accepted or Postponed, but the patch no longer works.
Please enter a comment when changing the Resolution to "Out of date", to record the nature of the problem and the previous state.
Also assign it back to the submitter, as they need to upload a new version.

Status Open, Resolution Postponed

The previous Resolution was None or Accepted, but for some reason (e.g., pending release) the patch should not be reviewed or applied until further notice.
The Resolution will normally change to None or Accepted next.
Please enter a comment when changing the Resolution to Postponed, to record the reason, the previous Resolution, and the conditions under which the patch should revert to Resolution None or Accepted. Also assign the patch to whoever is most likely able and willing to decide when the state should change again.

Status Deleted

Bit bucket.
Use only if it's OK for the patch and its SourceForge history to disappear.
As of 09-July-2000, SF does not actually throw away Deleted patches, but that may change.

A.2.: Python Patch Submission Guidelines

New: CNRI is no longer involved in Python patches. We no longer request legal disclaimers. Also, We're now using the SourceForge Patch Manager (a single mailing list became unmanageable).

Many people contribute patches to Python. We've set up a new system to deal with these. Here are the main guidelines:

Submit your patch to the patch manager interface at SourceForge. We strongly recommend that you register with SourceForge before submitting a patch. If you send patches directly to Guido you introduce an extra delay. Ditto for the "patches@python.org" mailing list address; this address should no longer be used for patch submission. 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 reporting mechanism instead. The bugs list is searchable; if you have a problem and you're not sure if it has been reported or fixed already, this is the first place to look. (There used to be a separate TODO list; we now prefer that you use the bugs list for suggestions and requests too.)
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 bug reporting mechanism.
We like context diffs. We grudgingly accept unified 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>.
We appreciate it if you send patches relative to the current CVS tree. These are our latest sources. It's almost a year since Python 1.5.2 was released, and many source files have been touched in more or less significant ways; a patch relative to Python 1.5.2 can cause a lot of extra pain to apply right. 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 the general Python Style Guide.