[Python-checkins] peps: add tentative release schedule and contributor guidelines
georg.brandl
python-checkins at python.org
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
More information about the Python-checkins
mailing list