要約

  • PythonのPEP手続は、公開討議、Steering Councilまたは承認されたPEP-Delegateによる判断、参照実装、主ソースリポジトリへの統合、リリース段階の制御を別々に扱う。
  • 決定からリリースまでの記録は、PEP、判断者、決議、リビジョン、対象ブランチ、段階、成果物を分けて残すべきであり、Accepted を出荷済みという意味にしてはならない。

「受け入れられた」は何を指すのか

Python が変更を受け入れた、という文は便利だが、PEP が公開されたこと、議論が終わったこと、Council が決めたこと、Delegate が指定された PEP を裁定したこと、CPython に実装が入ったこと、最終版が出たことを同時に指しうる。利用側が移行時期や保守責任を考えるなら、これらを同じ証拠として扱うことはできない。

PEP 1 で PEP は設計文書であり、主要な機能提案と共同の検討を支え、設計理由と反対意見を残す仕組みである。著者は合意形成を試み、異論を記録する。この公開性は重要だ。しかし、参加者の多さは正式な決定の代わりにならず、文章の存在は配布物の存在を示さない。

まず行為を分ける必要がある。編集上の確認は文書の体裁を扱う。討議は設計を試す。決議は提案の扱いを決める。参照実装は設計をコードに結びつける。リリース作業は特定の枝と成果物を安定化させる。前の段階が後の段階を自動的に権限づけるわけではない。

Delegate は限定された判断を担う

PEP の採否に関する最終権限は、選挙で選ばれた Steering Council にある。経験を持つ core developer は、特定の PEP の PEP-Delegate になりたいと申し出ることができ、Council が承認すればその PEP を承認または拒否できる。Delegate の適性に疑問があれば Council に持ち込める。

これは個人への無制限な権力移転ではない。技術的な文脈に近い判断を可能にしつつ、委任、異議、最終責任の経路を残す設計である。範囲は指定された PEP であり、言語全体、すべての将来リリース、すべてのリポジトリへ広がらない。

PEP 13 は Council に広い権限を認め、正式行為の前に合意を求め、権限の一部を委任でき、他の手段が失敗した際の最終上訴の場とする。だからこそ、Council の存在だけをすべての commit や日程の根拠にしてはならない。誰が、どの PEP について、どの記録に基づき決めたのかが必要である。

Accepted と Final と released は別の結び目である

PEP 1 は、Accepted の後、参照実装が完成し主ソースリポジトリに取り込まれて初めて Final になると定める。Accepted は実装完了の印ではない。Final は先行する判断と完成した参照実装を結びつける状態であり、単なる強い形容ではない。

さらに Provisional とされた PEP は、関連する変更が Python のリリースに入った後でも Reject または Withdraw になりうる。状態名から、永続性、すべての下流での互換性、広い採用、将来の欠陥の不存在まで読み取ることはできない。

開発サイクルも別の統制を置く。機能は in-development ブランチで進み、beta では maintenance branch が作られる。これにより現在の周期を安定化させながら次の周期を main で進められる。release candidate では、十分に重大でレビュー済みのバグ修正に変更が限られる。最終リリースを切る時点では、当該ブランチを変更できるのは release manager だけである。この制限はリリース面を守るもので、設計判断の著者を置き換えるものではない。

つなげるが、混同しない記録

決定の記録には PEP 番号と版、正規の討議、判断者、必要なら委任、決議へのリンク、状態を置く。そこで決まっていない対象版、実装の完了、backport、出荷時期も明示する。実装の記録には参照リビジョン、リポジトリ、ブランチ、公開された試験またはレビューを加える。リリースの記録にはブランチ、段階、成果物の識別子、release manager の行為、公開版を加える。

これは Python に新しい儀式を求める話ではない。討議を権限に、権限を完成コードに、統合コードを利用可能なリリースに読み替えないための編集上の節度である。

出典

  1. PEP 1 — PEP Purpose and Guidelines
  2. PEP 13 — Python Language Governance
  3. Python Developer’s Guide — Development cycle
  4. Lu Heng, The Multi-Stakeholder Mirage
  5. Lu Heng, Running-Code Primacy