From 737bcc346693a9cfb7b86b7c569008052fe7abe0 Mon Sep 17 00:00:00 2001 From: Peter Schneider-Kamp Date: Fri, 14 Jul 2000 01:28:47 +0000 Subject: small FAQ about Python CVS and patches at SourceForge --- Misc/sf-faq.html | 389 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 389 insertions(+) create mode 100644 Misc/sf-faq.html diff --git a/Misc/sf-faq.html b/Misc/sf-faq.html new file mode 100644 index 0000000..5d727f7 --- /dev/null +++ b/Misc/sf-faq.html @@ -0,0 +1,389 @@ + + + + + + + + +
+

+Python at SourceForge - Frequently Asked Questions

+ +

+0. Contents

+ +

+1. General

+ +
    +
  1. +What is SourceForge?
  2. + +
  3. +Where do I find Python there?
  4. +
+ +

+2. CVS

+ +
    +
  1. +How do I check out a CVS version of Python?
  2. + +
  3. +What settings should I use?
  4. + +
  5. +Troubleshooting: "Permission Denied"
  6. + +
  7. +Where can I learn more about CVS?
  8. +
+ +

+3. Patches

+ +
    +
  1. +How to make a patch?
  2. + +
  3. +How to submit patches?
  4. + +
  5. +How to change the status of a patch?
  6. +
+ +

+A. Appendix

+ +
    +
  1. +Patch Manager Guidelines [09.07.2000]
  2. + +
  3. +Python Patch Submission Guidelines [29.06.2000]
  4. +
+ +

+1. General

+ +

+1.1.:

+ +

+Q: What is SourceForge?

+ +

+A:

+SourceForge is a free hosting service +for OpenSource projects. The main website +is found at +
http://sourceforge.net
+ +

+1.2.:

+ +

+Q: Where can I find Python on SourceForge?

+ +

+A:

+The Python project page +can be found at +
http://sourceforge.net/projects/python
+ +

+2. CVS

+ +

+2.1.:

+ +

+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.2.:

+ +

+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.3.:

+ +

+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.4.:

+ +

+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
+ +

+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 | 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. +

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. +
  +

+A. Appendix

+ +

+A.1.: Patch Manager Guidelines

+ +

+Intended use of SourceForge patch status & "assigned to" fields

+revision 2                                          +09-Jul-2000 +

In general, the status field 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. +
  +

+Open

+ +
The initial status of all patches. +
The patch is under consideration, but has not been reviewed yet. +
The status 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]
+ +

+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 status 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).
+ +

+Closed

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

+Rejected

+ +
The patch has been reviewed and rejected. +
When the objections are addressed, the status may change to Open again. +
The person changing the status to Rejected should assign the patch +back to the submitter, or if it's clear the patch will never be accepted, +assign it to None. +
Note that SourceForge allows the submitter to overwrite the patch with +a new version.
+ +

+Out of date

+ +
Previous status was Open or Accepted or Postponed, but the +patch no longer works. +
Please enter a comment when changing the status to "Out of date", to +record the nature of the problem and the previous status. +
Also assign it back to the submitter, as they need to upload a new +version (note that SourceForge will not allow anyone other than the original +submitter to update the patch).
+ +

+Postponed

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

+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: +

+ + + -- cgit v0.12