add tentative release schedule and contributor guidelines

pep-0200.txt

@@ -6,7 +6,6 @@ Python-Version: 2.0
 Status: Incomplete
 
 
-
 Introduction
 
     This PEP describes the Python 2.0 release schedule, tracking the
@@ -16,12 +15,67 @@ Introduction
     CVS revision history of this file contains the definitive
     historical record.
 
+Tentative Release Schedule
+
+Aug. 14: All 2.0 PEPs finished / feature freeze
+Aug. 28: 2.0 beta 1
+Sep. 29: 2.0 final
+
+Guidelines for submitting patches and making changes
+
+Use good sense when committing changes.  You should know what we mean
+by good sense or we wouldn't have given you commit privileges <0.5
+wink>.  Some specific examples of good sense include:
+
+    - Do whatever the dictator tells you.
+
+    - Discuss any controversial changes on python-dev first.  If you
+      get a lot of +1 votes and no -1 votes, make the change.  If you 
+      get a some -1 votes, think twice; consider asking Guido what he 
+      thinks. 
+
+    - If the change is to code you contributed, it probably makes
+      sense for you to fix it.
+
+    - If the change affects code someone else wrote, it probably makes
+      sense to ask him or her first.
+
+    - You can use the SF Patch Manager to submit a patch and assign it
+      to someone for review.
+
+Any significant new feature must be described in a PEP and approved
+before it is checked in.
+
+Any significant code addition, such as a new module or large patch,
+must include test cases for the regression test and documentation.  A
+patch should not be checked in until the tests and documentation are
+ready.
+
+If you fix a bug, you should write a test case that would have caught
+the bug.
+
+If you commit a patch from the SF Patch Manager or fix a bug from the
+Jitterbug database, be sure to reference the patch/bug number in the
+CVS log message.  Also be sure to change the status in the patch
+manager or bug database (if you have access to the bug database).
+
+It is not acceptable for any checked in code to cause the regression
+test to fail.  If a checkin causes a failure, it must be fixed within
+24 hours or it will be backed out.
+
+All contributed C code must be ANSI C.  If possible check it with two
+different compilers, e.g. gcc and MSVC.
+
+All contributed Python code must follow Guido's Python style guide.
+http://www.python.org/doc/essays/styleguide.html
+
+It is understood that any code contributed will be released under an
+Open Source license.  Do not contribute code if it can't be released
+this way.
 
-
 Accepted and completed
 
 
-
 Accepted and in progress
 
     * SyntaxError enhancements - Fredrik Lundh
@@ -37,12 +91,11 @@ Accepted and in progress
     * SRE - Fredrik Lundh
       The test suite still fails on test_re.
 
-    * snprintf - owner???
+    * PyErr_SafeFormat / snprintf - owner???
       Use snprintf to avoid buffer overflows.  Need configure hackery
       to discovery if it is available on the current platform and a
       default implementation if it is not.
       http://www.python.org/pipermail/python-dev/2000-April/010051.html
-      This function is expected to be part of C9X (check).
 
     * Support for opcode arguments > 2**16 - Charles Waldman
       Source files longer than 32K and sequences with more than 32K
@@ -53,7 +106,6 @@ Accepted and in progress
       Make range(1, 10, 2) == [1:10:2]
 
 
-
 Open: proposed but not accepted or declined
 
     * List comprehensions - Tim Peters?
@@ -77,7 +129,6 @@ Open: proposed but not accepted or declined
       - http://www.python.org/pipermail/python-dev/1999-August/002252.html
 
 
-
 Declined