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/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4