🐘

[翻訳記事] PHP のリリースマネージャーについて

2022/12/24に公開約3,700字

はじめに

この記事は PHP Advent Calendar 2022 、最終日の記事です。

https://qiita.com/advent-calendar/2022/php

このエントリは、PHP 8.2 のリリースマネージャーを務める著者 Sergey Panteleev の許可を得て 原文 を翻訳し、最後に若干の解説を加えたものです。

[翻訳] The PHP 8.2 Release Managers

PHP 8.2 が2022年12月8日 にリリース予定です。このバージョンの新機能については、既に多くの記事が書かれています。よってこのエントリでは、PHP のリリースに携わる人達、つまりリリースマネージャー について書いてみることにします。

誰がリリースマネージャーになったの?

私 (Sergey Panteleev)は、今年の5月に PHP のリリースマネージャーチームに参加しました。しかし、私の知り合いの開発者の多くは、PHP のコミュニティにリリースマネージャーという"役割"があることはおろか、リリースマネージャーがどのような仕事をしているのかも知りませんでした。

PHP のそうした裏方的な側面について、考えたことがない人もいると思います。なので、この記事がそれを少しでも知る一助になれればと思います。

リリースマネージャーって何者?

リリースマネージャーは、PHPのバージョン[1]ごとに選出されます。

PHP 8.1 以降は、過去に何らかのバージョンですでにリリースマネージャーを経験した「ベテラン」1名と、そうでない「ルーキー(新人)」2名の、計3名のメンバーが選ばれるようになりました。

以前は、1人の人間が2つのバージョンのリリースマネージャーを同時に担当してはいけないというルールがありましたが、現在はそうしたルールはありません。むしろ、現在のリリースの「ルーキー」のうちの1人が、次のリリースの「ベテラン」を担当することが良い習慣になっています。

PHP 8.1 で「ルーキー」だった Ben Ramsey が、PHP 8.2 では「ベテラン」になっています。

どんなことをするの?

リリースマネージャーの仕事はなんでしょう?

まず、一番重要な仕事として、GitHub 上でバグやプルリクエストに優先順位を付け、分類することがあります。

PHP には PHP Foundation がスポンサーをしている開発チームがあります。なので、その作業は容易です。コア開発者がそのタスクの多くを自分たちで行ないます: つまり、それはコア開発者の専門分野なので、リリースマネージャーは彼らの意見に耳を傾けるのが仕事です。

もちろん、直接 PHP をリリースすることもリリースマネージャーの仕事です(まあ、これはわかりますよね😅)。

GA版のリリースに先立ち、6ヶ月間のプレリリースフェーズが実施されます:

プレリリースフェーズでは、2週間ごとに、alpha1 から RC6 (PHP 8.2 の場合は RC7) までの PHP のテストバージョンをリリースします。

GA版がリリースされたブランチは、その後さらに3年間サポートされます。2年間のアクティブサポートがあり、その後1年間 セキュリティリリースが行われます。その後リリースマネージャーは退任します。

何のためにいるの?

リリースマネージャーには、どの機能を盛り込むかを決める権限はありません。新機能はすべて RFC化 され、投票することで決まります。

コア開発者とコミュニティが開発をリードするのであれば、なぜ PHP にリリースマネージャーが必要なのでしょうか?

リリースマネージャーの仕事は、リリース日を把握し、PHP のブランチを良好な状態に保ち、異常があった場合に対応することです。

時には物議を醸す場面もありますが、リリースマネージャーは一種の仲裁裁判所のようなものです: つまり、最終的な決定に対して大きな責任を負っています。

リリースマネージャーになるには?

まもなく、PHPチームは PHP 8.3 のリリースマネージャーの公募を開始する予定です。

あなたがすべきことは、立候補することだけです。

選挙は STV で行われ、2名のルーキーが選ばれ、3年半にわたってPHPに貢献することになります。

おわりに

Ben, Pierrick, サポートしてくれて本当にありがとう。

立候補することを恐れず、私たちの愛するプログラミング言語を良くしていきましょう💙 🐘

解説

リリースマネージャーという役割は、OSS ではよく見られる役回りです。少しググってみるだけでも、 GitLab や、RubyApache Hadoop などの例が見つかります。

ある特定時点のリリースに何を入れるか、入れないかを決め、ソフトウェアとしての成果物を世に届ける営みは、OSS 開発者でなくとも多くの人に経験があるものでしょう。

リリースマネージャーについては、任命されるプロセスや、責務についてプロジェクト毎に差があれど、以下については共通しているように見えます。

  • リリースブランチを良好な状態に保つ
  • リリース作業を行う

一見簡単な風に書いていますが、PHP については 内部構造をある程度知った上で、コードや後方互換性を壊さないようにブランチやバグを管理する仕事をします。CI が普及してきているとはいえ、多くのコードやパッチが開発されていく中でそれを整理し、管理するのは大変な役目です。技術的な判断だけでなく、調整能力も必要です。

そうした重責を、コア開発者や過去のリリースマネージャー(ベテラン)などが協働して分散する体制が作れているのが、PHP の開発コミュニティの良さの一つなのでしょう。PHP 8.1 以降、ベテラン1名とルーキー2名の協働体制になったことが上の翻訳記事でも触れられています。PHP に多大な貢献をしてきた nikic がメイン開発者を降りPHP Foundation が設立されて以降、こうした開発体制全体をスケールさせていく試みは、これからも様々な側面で続いていくと思われます。

ただそうであっても、3年以上もひとつのブランチを見守っていくのは大変です。勇気を持って手を挙げた Sergay に、同じ Documentation Team の仲間[2]として、私は深い敬意を表します。

脚注
  1. (訳注) ここでいう「PHPのバージョン」とは、セマンティックバージョニング でいうところのマイナーバージョンを指しています。但し、PHP の場合はマイナーバージョンであっても互換性を平気で壊すので、PHP のバージョンナンバーは厳密な意味でのそれではありません。 ↩︎

  2. (訳注) Sergay Panteleev は、PHPマニュアル ロシア語版 のメンテナでもあります。 ↩︎

Discussion

ログインするとコメントできます