[Python-Dev] Pythonb at SourceForge FAQ

Greg Stein gstein@lyra.org
Thu, 13 Jul 2000 17:45:54 -0700


Since we don't have ready access to python.org, I would suggest turning on
the Python web pages at SF and placing it there.

(of course, with obvious links from python.sourceforge.net to python.org)

Having a FAQ about Python/SF at SF makes sense to me :-)

Cheers,
-g

On Fri, Jul 14, 2000 at 02:38:33AM +0000, Peter Schneider-Kamp wrote:
> I started a small FAQ. Where should I put this?
> 
> HTML file attached.
> 
> Peter
> --
> Peter Schneider-Kamp          ++47-7388-7331
> Herman Krags veg 51-11        mailto:peter@schneider-kamp.de
> N-7050 Trondheim              http://schneider-kamp.de
> 
>              Python at SourceForge - Frequently Asked Questions
>                                       
>                                   0. Contents
>                                        
> [1]1. General
> 
>     1. [2]What is SourceForge?
>     2. [3]Where do I find Python there?
>        
> [4]2. CVS
> 
>     1. [5]How do I check out a CVS version of Python?
>     2. [6]What settings should I use?
>     3. [7]Troubleshooting: "Permission Denied"
>     4. [8]Where can I learn more about CVS?
>        
> [9]3. Patches
> 
>     1. [10]How to make a patch?
>     2. [11]How to submit patches?
>     3. [12]How to change the status of a patch?
>        
> [13]A. Appendix
> 
>     1. [14]Patch Manager Guidelines [09.07.2000]
>     2. [15]Python Patch Submission Guidelines [29.06.2000]
>        
>                                   1. General
>                                        
>   1.1.:
>   
>     Q: What is SourceForge?
>     
>     A:
>     
>    [16]SourceForge is a free hosting service for [17]OpenSource projects.
>    The main website is found at
>    
>      [18]http://sourceforge.net
>      
>   1.2.:
>   
>     Q: Where can I find Python on SourceForge?
>     
>     A:
>     
>    The [19]Python project page can be found at
>    
>      [20]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/pyth
>      on
>      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
>    
>      [21]http://sfdocs.sourceforge.net/sfdocs
>      
>    For general (and more advanced) information consult the free CVS Book
>    at
>    
>      [22]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 [23]Patch Submission Guidelines at
>    
>      [24]http://www.python.org/patches
>      
>    A [25]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 [26]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:
>      * Submit your patch to the [27]patch manager interface at
>        [28]SourceForge. We strongly recommend that you [29]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 [30]Python Bugs List
>        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 [31]Python
>        Bugs List instead.
>      * 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 [32]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 [33]style requirements. Please
>        have a look at these before writing new code. Also have a look at
>        the general [34]Python Style Guide.
> 
> References
> 
>    1. file://localhost/tmp/sf-faq.html#general
>    2. file://localhost/tmp/sf-faq.html#g1
>    3. file://localhost/tmp/sf-faq.html#g2
>    4. file://localhost/tmp/sf-faq.html#cvs
>    5. file://localhost/tmp/sf-faq.html#c1
>    6. file://localhost/tmp/sf-faq.html#c2
>    7. file://localhost/tmp/sf-faq.html#c3
>    8. file://localhost/tmp/sf-faq.html#c4
>    9. file://localhost/tmp/sf-faq.html#patches
>   10. file://localhost/tmp/sf-faq.html#p1
>   11. file://localhost/tmp/sf-faq.html#p2
>   12. file://localhost/tmp/sf-faq.html#p3
>   13. file://localhost/tmp/sf-faq.html#appendix
>   14. file://localhost/tmp/sf-faq.html#a1
>   15. file://localhost/tmp/sf-faq.html#a2
>   16. http://sourceforge.net/
>   17. http://opensource.org/
>   18. http://sourceforge.net/
>   19. http://sourceforge.net/projects/python
>   20. http://sourceforge.net/projects/python
>   21. http://sfdocs.sourceforge.net/sfdocs
>   22. http://cvsbook.red-bean.com/cvsbook.html#Introduction
>   23. http://www.python.org/patches
>   24. http://www.python.org/patches
>   25. file://localhost/tmp/sf-faq.html#a2
>   26. file://localhost/tmp/sf-faq.html#a1
>   27. http://sourceforge.net/patch/?group_id=5470
>   28. http://sourceforge.net/project/?group_id=5470
>   29. http://sourceforge.net/account/register.php
>   30. http://www.python.org/search/search_bugs.html
>   31. http://www.python.org/search/search_bugs.html
>   32. http://sourceforge.net/cvs/?group_id=5470
>   33. http://www.python.org/patches/style.html
>   34. http://www.python.org/doc/essays/styleguide.html


-- 
Greg Stein, http://www.lyra.org/