[LWN Logo]
[Timeline]
From: "A.M. Kuchling" <amk1@erols.com>
To: python-list@python.org
Subject: New Python development process
Date: Tue, 26 Sep 2000 22:46:17 -0400

Here's a new section for the "What's New in Python 2.0" document
describing the new development process.  I'd greatly appreciate
comments on it, both from readers who can point out hard-to-understand
bits and suggest further interesting points that should be made, and
also from python-dev people who can point out inaccuracies in my
description of the current development process.

(*Not* cross-posted to python-dev, since I hate cross-posting.)

--amk

                           3 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'':
   
     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.
     
   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
   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 http://sourceforge.net/projects/python/.

-- 
http://www.python.org/mailman/listinfo/python-list