原文:http://www.python.org/dev/peps/pep-0002/
| PEP | 2 |
| Title | Procedure for Adding New Modules |
| Version | 56077 |
| Last-Modified | 2007-06-22 20:50:54 +0200 (Fri, 22 Jun 2007) |
| Author | Martijn Faassen <faassen at infrae.com> |
| Status | Active |
| Type | Process |
| Created | 07-Jul-2001 |
| Post-History | 07-Jul-2001, 09-Mar-2002 |
Python標準ライブラリは、Pythonの成功に多大な寄与をしました。”バッテリー内蔵”の言語は、標準ライブラリだけで人々を生産的にしました。そのため、このライブラリが言語と共に発展し、そして、その発展が励みになることが重要となるのです。
このライブラリは、主要な開発者だけでなく、Pythonコミュニティでの各分野での専門家からも多大な寄与さらに、コミュニティのメンバーはこの標準ライブラリのユーザでもあり、偉大なほど多様な設定を適用してくれました。これはコミュニティにライブラリ中のバグを発見し、報告する能力をもたらしています。失われたものごとは、付け加えられるのです(訳注:定型句？)。
通常、新しい機能は新しいモジュールの形となってライブラリに付け加えられます。このPEPは、新しいモジュールを追加する手続きについて述べています。また、古い使われていないモジュールを標準ライブラリから取り除く手続きも含まれています。最後に、ライブラリを完全なものにするために、既存のモジュールを変更することに関しても述べられています。PEP 3とPEP 5はこの手続きに関するガイドラインを提供しています。既存のモジュールに対する継続的なメンテナンスは、新しいモジュールを付け加える決定に関わらず、完全なものになるために必要な部分です。そのため、このPEPはメンテナンスの問題に関する適切なコンセプト(インテグレータ、メンテナ)を紹介します。
インテグレータは以下の責任を持つ人々の集まりです。
標準ライブラリへの全ての貢献は一人以上のメンテナを必要とします。これはXML-SIGのような独立した、しかし継続的な人々の集まりです。グループはメンテナンスの仕事に応じて細分化されます。一人以上のメンテナがメンテナ長(Head maintainer)となります(この人は大体の場合において、主要開発者である)。メンテナ長は、インテグレータがこの文書で後に述べるような特定の問題を解決してほしいと指し示しやすい人々です。
標準ライブラリへの貢献は、一人以上の開発者によって開発されます。(PEPの貢献への誘いにて述べられるような)特別な事情がない限り、最初のメンテナは元々の開発者です。
開発者が貢献を標準ライブラリに受け入れて欲しいと願ったとき、最初にメンテナのグループを作ってください(通常最初は彼ら自身で構成されます)。
それから、そのグループはライブラリPEPと呼ばれるPEPの手続きを進めます。ライブラリPEPはスタンダードトラックのPEPのうちの特別なPEPです。このライブラリPEPは提案された貢献の概要と、参照実装を提供することになります。このPEPはなぜこの貢献が標準ライブラリの一部とならなければならないのかという理由を含む必要があります。
一人以上のメンテナがPEPチャンピオン(著者に挙がっている人々がチャンピオンです)として、手続きを進める必要があります。このPEPチャンピオン(達)が、最初のメンテナ長です。
PEP 1で述べられた通り、スタンダードトラックPEPは設計と参照実装を含まなければなりません。ライブラリPEPは通常のスタンダードトラックPEPと異なり、
常にPEPが書かれるより前に参照実装がなくてはなりません。また、この参照実装はインテグレータによってレビューされ、コミュニティからコメントを受け付けなくてはなりません。参照実装こそが提案されている貢献なのです。
この異なる要求事項は、以下の理由によって求められています。
ソースコードと文章を調べるときに、インテグレータこそが標準ライブラリへの貢献を正しく判断できるからです。すなわち、参照実装はPEPを勉強している人々に取って常に必要なのです。(訳注: 自信無)
貢献が拒否されたとしても、標準ライブラリ以外にとっては有益な場合があります。そのため、開発者の努力を無駄にするリスクを低くします。
インテグレータの真剣な貢献が良い印象を与え、不真面目な提案を数多く検討しなければならない事態を防ぎます。
一度ライブラリPEPがレビューに申請されると、インテグレータはそれを評価します。PEPはPEP 1で述べられた標準PEPのワークフローに則ります。もしそのPEPが受理された場合、メンテナ長に回覧され、その貢献を標準ライブラリに統合する準備にとりかかります。
貢献が受理されれば、インテグレータとメンテナの両方にとってその仕事が終わり、というわけではありません。インテグレータはインテグレータは標準ライブラリ中のどんなバグ報告も、適切なメンテナ長に転送します。
標準ライブラリのリリースに備えて機能を凍結する準備をする前に、インテグレータはメンテナ長と一緒に、次のリリースに含む更新がないか全ての貢献をチェックします。インテグレータはその更新を、後方互換性が保たれてるかなどを評価します。また、更新が大きすぎる場合はPEPが必要となる場合もあります
メンテナ長はPythonの開発プロセスを最新に保つために活発な役目を担う必要があります。もしメンテナ長がその役目をできないばあい、インテグレータに降格するというアナウンスをする必要があります。これにより、メンテナの残りの人が昇格することになります。インテグレータはメンテナ長とE-メールで連絡を取り合えるようにしておく必要があります。
(もうメンテナがいないなどによって)メンテナ長が見つからない場合は、インテグレータは昇格するための新しいメンテナをコミュニティから広く募集します。もしも誰もいない場合、インテグレータはPEP 4で述べられているように、その貢献を廃止宣言する可能性があります。
インテグレータはメンテナ(最低限メンテナ長と)と常に連絡をとれるような方法が必要です。そのためには、全てのメンテナ長がメーリングリスト(python-devが適当か)を購読することなどが方法として挙げられます。他の可能性としては、PEPリストと同じようなリストを全ての貢献について作成し、それにメンテナ長の連絡先も併記しておくのです。PEPを要求する新しい貢献には、PEPリストの一部として実際なっています(訳注: 自信無)。しかし、新しいモジュールを導入したPEPの著者と管理者とが別になる事態が起きてしまいます。
この件は、全ての技術的な問題に関連します。チェックイン権限、コーディングスタイルの要求、文書化の要求、テストの要求。これに関しては別のPEPで述べる方が良いでしょう。
現在の標準ライブラリはメンテナの間で細分化されるべきか？多くの部分にはすでに(非公式の)メンテナがいます。もっと明文化させることがいい考えかもしれません。
‘貢献(contribution)’よりもっといい単語があるかもしれません。’貢献’という言葉はライブラリに統合されたあとも貢献を止めないというその(開発や管理の)プロセスを十分に意味していないかもしれません。
関連性とは神話のカタログか？(訳注: 意味がとれない)