214 lines
8.0 KiB
Plaintext
214 lines
8.0 KiB
Plaintext
PEP: 2
|
|
Title: Procedure for Adding New Modules
|
|
Version: $Revision$
|
|
Last-Modified: $Date$
|
|
Author: Martijn Faassen <faassen@infrae.com>
|
|
Status: Superseded
|
|
Type: Process
|
|
Content-Type: text/x-rst
|
|
Created: 07-Jul-2001
|
|
Post-History: 07-Jul-2001, 09-Mar-2002
|
|
|
|
|
|
|
|
PEP Replacement
|
|
===============
|
|
|
|
This PEP has been superseded by the updated material in the Python
|
|
Developer's Guide [1]_.
|
|
|
|
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 or 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?
|
|
|
|
References
|
|
==========
|
|
|
|
.. [1] Adding to the Stdlib
|
|
(http://docs.python.org/devguide/stdlibchanges.html)
|
|
|
|
Copyright
|
|
=========
|
|
|
|
This document has been placed in the public domain.
|
|
|
|
..
|
|
Local Variables:
|
|
mode: indented-text
|
|
indent-tabs-mode: nil
|
|
fill-column: 70
|
|
coding: utf-8
|
|
End:
|