別のPostgreSQLCommitfestの管理

以前にPostgreSQLのcommitfestの管理について書いたことがあります。

PostgreSQL 13の開発サイクル中に、私はそれをやり直しました。今回は別の戦略を使用しましたが、これは主に、十分な注意が払われていなかった非常に古いパッチが過剰に蓄積されていると感じたためです。そのため、バグ修正（常に特殊なケース）は別として、私は長い間キューに残っていたパッチに焦点を合わせました。

私が気づいたことの1つは、以前のcommitfestマネージャーからの繰り返しの提案の後でも、フィードバックごと、またはビット回転ごとに一部のパッチが更新されていないことです。それらは、他のアクティビティなしで、あるcommitfestから別のcommitfestに移動します。それらのいくつかは、PostgreSQL開発から移行した人々からのものです。他の人は放棄されたプロジェクトかもしれません。私の意見では、何も起こらなければそれらを維持する意味がないので、他の人が望むなら見て、所有権を取得できるように、それらを閉じてリストを提供しました。 （フォローアップ投稿にはさらにいくつかが含まれています）。私の希望は、誰かがこれらの機能に興味を持っている場合は、パッチを受け取り、フィードバックやビット腐敗に対処した後に再送信することです。

もう1つ一般的になりつつあるのは、多くのパッチがほとんどレビューなしで残っていることです。あるいは、かなりのレビューがあっても、コミッターがパッチを取得するまでには至らないこともあります。それらのケースのいくつかでは、私のアプローチは、レビューに役立つと思った特定の人々をプロデュースすることでした。それ以外の場合は、自分でパッチを確認しました。時々、質問をするだけで他の人が議論に参加するのに十分であるように思われるので、直接の貢献が少なくても、それは有用なより大きな効果をもたらします。

また、自分でいくつかのパッチのレビュー担当者/コミッターとして登録しました。私はそれで適度に成功し、24のコミットと10のcommitfest-entriesがcommitedとマークされました…またはcommitfestエントリの総数の約25％で終わりました。悪くないですよね？

閉鎖レポートのメールで、次の表を投稿しました：

注目に値することの1つは、「フィードバックとともに返される」がずっと低いままで、最後に跳ね上がっただけで、数が多かったことです。将来のCFMが行うことを提案する演習は、そのようなパッチを次のcommitfestに移動するのではなく、マンデートの最後に非アクティブなビット腐敗パッチを正常に閉じることです。後者の操作は、CF中にアクティブだったパッチ、まだ適用されているパッチ、または最近作成者を待っているパッチ用に予約する必要があります。注目に値するもう1つのことは、コミットされたパッチの数です…というか、それがどれだけゆっくりと上昇したかです。一部のコミッターは気を取られた Postgres12のリリースを支援します。他の人は、そうではなかったパッチで非常に活発でした commitfestの一部です。次回は何人かのコミッターがもっと注意を払うことになると思います。そうすれば、実際の進歩が見られるでしょう。

ThomasMunroのcommitfestボットは非常に貴重なツールです。パッチの作成者は、これにもっと注意を払う必要があります。そのサービスをコミュニティのcommitfestインフラストラクチャに統合する方がはるかに優れています。ラウンドチュートが必要だと思います。

私が欲しかったもの：

• ローカルクエリ用に更新されたcommitfestデータのpg_dump。
• 私は適切な人に尋ねることによって毎週ダンプを取得し、いくつかの大雑把な質問を書きました。おそらく、アプリのレポートなどのクエリ（の改良版）の結果を提供することができます。
• commitfestアプリのフィルタリングの改善も歓迎されます。
• パッチをまとめて移動する行為 次のCFへの移行はより適切に自動化される可能性があります。

全体として、今月は非常に満足のいく月であり、PostgreSQL開発にとって貴重なものであったことを願っています。 2ndQuadrantが私にこれを行うために月を過ごす機会を与えてくれたことに感謝しています…しかしそれでも、私は通常の職務に戻ることを楽しみにしています。