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