mirrors/cpython
0
0
Fork 0
mirror of https://github.com/python/cpython.git synced 2024-12-12 03:04:15 +08:00
Code Issues Packages Projects Releases Wiki Activity

Added a section describing the new development process. Part of it

Browse Source 
comes from two comp.lang.tcl postings of mine, with much rewriting
   and expansion of the material.
Note that 2.0 will be released in the autumn, not the summer.
This commit is contained in:
Andrew M. Kuchling 2000-09-27 02:36:10 +00:00
parent ef850def44
commit be870dd96f
1 changed files with 87 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
Doc/whatsnew/whatsnew20.tex
View File

@ -18,7 +18,7 @@ the beta cycle before the final release of Python 2.0.
}
A new release of Python, version 2.0, will be released some time this
summer. Beta versions are already available from
autumn. Beta versions are already available from
\url{http://www.pythonlabs.com/products/python2.0/}. This article
covers the exciting new features in 2.0, highlights some other useful
changes, and points out a few incompatible changes that may require
@ -54,6 +54,92 @@ just going straight to 2.0. Most of the really interesting features
described in this document are only in 2.0, because a lot of work was
done between May and September.
% ======================================================================
\section{New Development Process}
The most important change in Python 2.0 may not be to the code at all,
but to how Python is developed.
In May of 2000, the Python CVS tree was moved to SourceForge.
Previously, there were roughly 7 or so people who had write access to
the CVS tree, and all patches had to be inspected and checked in by
one of the people on this short list. Obviously, this wasn't very
scalable. By moving the CVS tree to SourceForge, it became possible
to grant write access to more people; as of September 2000 there were
27 people able to check in changes, a fourfold increase. This makes
possible large-scale changes that wouldn't be attempted if they'd have
to be filtered through the small group of core developers. For
example, one day Peter Schneider-Kamp took it into his head to drop
K\&R C compatibility and convert the C source for Python to ANSI
C. After getting approval on the python-dev mailing list, he launched
into a flurry of checkins that lasted about a week, other developers
joined in to help, and the job was done. If there were only 5 people
with write access, probably that task would have been viewed as
``nice, but not worth the time and effort needed'' and it wouldn't
never have been done.
SourceForge also provides tools for tracking bug and patch
submissions, and in combination with the public CVS tree, they've
resulted in a remarkable increase in the speed of development.
Patches now get submitted, commented on, revised by people other than
the original submitter, and bounced back and forth between people
until the patch is deemed worth checking in. This didn't come without
a cost: developers now have more e-mail to deal with, more mailing
lists to follow, and special tools had to be written for the new
environment. For example, SourceForge sends default patch and bug
notification e-mail messages that are completely unhelpful, so Ka-Ping
Yee wrote an HTML screen-scraper that sends more useful messages.
The ease of adding code caused a few initial growing pains, such as
code was checked in before it was ready or without getting clear
agreement from the developer group. The approval process that has
emerged is somewhat similar to that used by the Apache group.
Developers can vote +1, +0, -0, or -1 on a patch; +1 and -1 denote
acceptance or rejection, while +0 and -0 mean the developer is mostly
indifferent to the change, though with a slight positive or negative
slant. The most significant change from the Apache model is that
Guido van Rossum, who has Benevolent Dictator For Life status, can
ignore the votes of the other developers and approve or reject a
change, effectively giving him a +Infinity / -Infinity vote.
Producing an actual patch is the last step in adding a new feature,
and is usually easy compared to the earlier task of coming up with a
good design. Discussions of new features can often explode into
lengthy mailing list threads, making the discussion hard to follow,
and no one can read every posting to python-dev. Therefore, a
relatively formal process has been set up to write Python Enhancement
Proposals (PEPs), modelled on the Internet RFC process. PEPs are
draft documents that describe a proposed new feature, and are
continually revised until the community reaches a consensus, either
accepting or rejecting the proposal. Quoting from the introduction to
PEP 1, ``PEP Purpose and Guidelines'':
\begin{quotation}
PEP stands for Python Enhancement Proposal. A PEP is a design
document providing information to the Python community, or
describing a new feature for Python. The PEP should provide a
concise technical specification of the feature and a rationale for
the feature.
We intend PEPs to be the primary mechanisms for proposing new
features, for collecting community input on an issue, and for
documenting the design decisions that have gone into Python. The
PEP author is responsible for building consensus within the
community and documenting dissenting opinions.
\end{quotation}
Read the rest of PEP 1 for the details of the PEP editorial process,
style, and format. PEPs are kept in the Python CVS tree on
SourceForge, though they're not part of the Python 2.0 distribution,
and are also available in HTML form from
\url{http://python.sourceforge.net/peps/}. As of September 2000,
there are 25 PEPS, ranging from PEP 201, ``Lockstep Iteration'', to
PEP 225, ``Elementwise/Objectwise Operators''.
To report bugs or submit patches for Python 2.0, use the bug tracking
and patch manager tools available from the SourceForge project page,
at \url{http://sourceforge.net/projects/python/}.
% ======================================================================
\section{Unicode}