[Python-checkins] peps: add tentative release schedule and contributor guidelines

Wed Mar 23 21:23:12 CET 2011

http://hg.python.org/peps/rev/281696d18779
changeset: 43:281696d18779
user: Jeremy Hylton <jeremy at alum.mit.edu>
date: Tue Jul 25 14:11:19 2000 +0000
summary:
 add tentative release schedule and contributor guidelines
files:
 pep-0200.txt | 65 +++++++++++++++++++++++++++++++++++----
 1 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/pep-0200.txt b/pep-0200.txt
--- a/pep-0200.txt
+++ b/pep-0200.txt
@@ -6,7 +6,6 @@
 Status: Incomplete
 
 
-
 Introduction
 
 This PEP describes the Python 2.0 release schedule, tracking the
@@ -16,12 +15,67 @@
 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 @@
 * 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 @@
 Make range(1, 10, 2) == [1:10:2]
 
 
-
 Open: proposed but not accepted or declined
 
 * List comprehensions - Tim Peters?
@@ -77,7 +129,6 @@
 - http://www.python.org/pipermail/python-dev/1999-August/002252.html
 
 
-
 Declined
 
 
-- 
Repository URL: http://hg.python.org/peps
