200 lines
8.1 KiB
Plaintext
200 lines
8.1 KiB
Plaintext
PEP: 2
|
||
Title: Procedure for Adding New Modules
|
||
Version: $Revision$
|
||
Last-Modified: $Date$
|
||
Author: faassen@infrae.com (Martijn Faassen)
|
||
Status: Active
|
||
Type: Process
|
||
Created: 07-Jul-2001
|
||
Post-History: 07-Jul-2001, 09-Mar-2002
|
||
|
||
|
||
Introduction
|
||
|
||
The Python Standard Library contributes significantly to Python's
|
||
success. The language comes with "batteries included", so it is
|
||
easy for people to become productive with just the standard
|
||
library alone. It is therefore important that this library grows
|
||
with the language, and that such growth is supported and
|
||
encouraged.
|
||
|
||
Many contributions to the library are not created by core
|
||
developers but by people from the Python community who are experts
|
||
in their particular field. Furthermore, community members are
|
||
also the users of the standard library, applying it in a great
|
||
diversity of settings. This makes the community well equipped to
|
||
detect and report gaps in the library; things that are missing but
|
||
should be added.
|
||
|
||
New functionality is commonly added to the library in the form of
|
||
new modules. This PEP will describe the procedure for the
|
||
_addition_ of new modules. PEP 4 deals with procedures for
|
||
deprecation of modules; the _removal_ of old and unused modules
|
||
from the standard library. Finally there is also the issue of
|
||
_changing_ existing modules to make the picture of library
|
||
evolution complete. PEP 3 and PEP 5 give some guidelines on this.
|
||
The continued maintenance of existing modules is an integral part
|
||
of the decision on whether to add a new module to the standard
|
||
library. Therefore, this PEP also introduces concepts
|
||
(integrators, maintainers) relevant to the maintenance issue.
|
||
|
||
|
||
Integrators
|
||
|
||
The integrators are a group of people with the following
|
||
responsibilities:
|
||
|
||
- They determine if a proposed contribution should become part of
|
||
the standard library.
|
||
|
||
- They integrate accepted contributions into the standard library.
|
||
|
||
- They produce standard library releases.
|
||
|
||
This group of people shall be PythonLabs, led by Guido.
|
||
|
||
|
||
Maintainer(s)
|
||
|
||
All contributions to the standard library need one or more
|
||
maintainers. This can be an individual, but it is frequently a
|
||
group of people such as the XML-SIG. Groups may subdivide
|
||
maintenance tasks among themselves. One ore more maintainers
|
||
shall be the _head maintainer_ (usually this is also the main
|
||
developer). Head maintainers are convenient people the
|
||
integrators can address if they want to resolve specific issues,
|
||
such as the ones detailed later in this document.
|
||
|
||
|
||
Developers(s)
|
||
|
||
Contributions to the standard library have been developed by one
|
||
or more developers. The initial maintainers are the original
|
||
developers unless there are special circumstances (which should be
|
||
detailed in the PEP proposing the contribution).
|
||
|
||
|
||
Acceptance Procedure
|
||
|
||
When developers wish to have a contribution accepted into the
|
||
standard library, they will first form a group of maintainers
|
||
(normally initially consisting of themselves).
|
||
|
||
Then, this group shall produce a PEP called a library PEP. A
|
||
library PEP is a special form of standards track PEP. The library
|
||
PEP gives an overview of the proposed contribution, along with the
|
||
proposed contribution as the reference implementation. This PEP
|
||
should also contain a motivation on why this contribution should
|
||
be part of the standard library.
|
||
|
||
One or more maintainers shall step forward as PEP champion (the
|
||
people listed in the Author field are the champions). The PEP
|
||
champion(s) shall be the initial head maintainer(s).
|
||
|
||
As described in PEP 1, a standards track PEP should consist of a
|
||
design document and a reference implementation. The library PEP
|
||
differs from a normal standard track PEP in that the reference
|
||
implementation should in this case always already have been
|
||
written before the PEP is to be reviewed for inclusion by the
|
||
integrators and to be commented upon by the community; the
|
||
reference implementation _is_ the proposed contribution.
|
||
|
||
This different requirement exists for the following reasons:
|
||
|
||
- The integrators can only properly evaluate a contribution to the
|
||
standard library when there is source code and documentation to
|
||
look at; i.e. the reference implementation is always necessary
|
||
to aid people in studying the PEP.
|
||
|
||
- Even rejected contributions will be useful outside the standard
|
||
library, so there will a lower risk of waste of effort by the
|
||
developers.
|
||
|
||
- It will impress the integrators of the seriousness of
|
||
contribution and will help guard them against having to evaluate
|
||
too many frivolous proposals.
|
||
|
||
Once the library PEP has been submitted for review, the
|
||
integrators will then evaluate it. The PEP will follow the normal
|
||
PEP work flow as described in PEP 1. If the PEP is accepted, they
|
||
will work through the head maintainers to make the contribution
|
||
ready for integration.
|
||
|
||
|
||
Maintenance Procedure
|
||
|
||
After a contribution has been accepted, the job is not over for
|
||
both integrators and maintainers. The integrators will forward
|
||
any bug reports in the standard library to the appropriate head
|
||
maintainers.
|
||
|
||
Before the feature freeze preparing for a release of the standard
|
||
library, the integrators will check with the head maintainers for
|
||
all contributions, to see if there are any updates to be included
|
||
in the next release. The integrators will evaluate any such
|
||
updates for issues like backwards compatibility and may require
|
||
PEPs if the changes are deemed to be large.
|
||
|
||
The head maintainers should take an active role in keeping up to
|
||
date with the Python development process. If a head maintainer is
|
||
unable to function in this way, he or she should announce the
|
||
intention to step down to the integrators and the rest of the
|
||
maintainers, so that a replacement can step forward. The
|
||
integrators should at all times be capable of reaching the head
|
||
maintainers by email.
|
||
|
||
In the case where no head maintainer can be found (possibly
|
||
because there are no maintainers left), the integrators will issue
|
||
a call to the community at large asking for new maintainers to
|
||
step forward. If no one does, the integrators can decide to
|
||
declare the contribution deprecated as described in PEP 4.
|
||
|
||
|
||
Open issues
|
||
|
||
There needs to be some procedure so that the integrators can
|
||
always reach the maintainers (or at least the head maintainers).
|
||
This could be accomplished by a mailing list to which all head
|
||
maintainers should be subscribed (this could be python-dev).
|
||
Another possibility, which may be useful in any case, is the
|
||
maintenance of a list similar to that of the list of PEPs which
|
||
lists all the contributions and their head maintainers with
|
||
contact info. This could in fact be part of the list of the PEPs,
|
||
as a new contribution requires a PEP. But since the
|
||
authors/owners of a PEP introducing a new module may eventually be
|
||
different from those who maintain it, this wouldn't resolve all
|
||
issues yet.
|
||
|
||
Should there be a list of what criteria integrators use for
|
||
evaluating contributions? (Source code but also things like
|
||
documentation and a test suite, as well as such vague things like
|
||
'dependability of the maintainers'.)
|
||
|
||
This relates to all the technical issues; check-in privileges,
|
||
coding style requirements, documentation requirements, test suite
|
||
requirements. These are preferably part of another PEP.
|
||
|
||
Should the current standard library be subdivided among
|
||
maintainers? Many parts already have (informal) maintainers; it
|
||
may be good to make this more explicit.
|
||
|
||
Perhaps there is a better word for 'contribution'; the word
|
||
'contribution' may not imply enough that the process (of
|
||
development and maintenance) does not stop after the contribution
|
||
is accepted and integrated into the library.
|
||
|
||
Relationship to the mythical Catalog?
|
||
|
||
|
||
Copyright
|
||
|
||
This document has been placed in the public domain.
|
||
|
||
|
||
|
||
Local Variables:
|
||
mode: indented-text
|
||
indent-tabs-mode: nil
|
||
fill-column: 70
|
||
End:
|