過去数年間PostgreSQL開発をフォローしている場合は、おそらく commitfest managerという用語を聞いたことがあるでしょう。 何回か。あなたはおそらくcommitfestが何であるかをすでに知っていますが、なぜマネージャーがいるのですか？今年の1月にかなりの時間を費やして管理したので、説明します。
commitfest中に適用されたパッチ
本質的に、PostgreSQL commitfestは、PostgreSQLコードベースへの統合を待っているパッチのコレクションにすぎません。 commitfestの動作原理は、 pgsql-hackersに送信された各パッチです。 タイムリーにレビューする必要があります。十分な回数レビューおよび改訂されると、パッチはコミッターによるPostgreSQLへの永続的な組み込みの候補になります。
commitfestワークフローの場合：新しいパッチはそれぞれ、「レビューが必要」状態のcommitfestで有効になります。 「拒否された」（作成者の脆弱な心を壊す）、「コミットされた」（作成者の日、週、または月を作成する）、または「フィードバックとともに返される」（作成者はそれを維持する必要があり、何を知っているか）として閉じることができます。パッチを改善し、将来のcommitfestで復活させるために行うこと）。 「作成者を待っています」という短期間のステータスもあります。これは、「レビューが必要」として数日以内に新しいバージョンのパッチが作成されると予想される迅速なフィードバックに使用されます。 「コミット済み」とマークされたものがあり、作成者が良いフィードバックを得る限り、物事は進んでいます。PostgreSQLは成長し、進化し、成熟して次の「メジャーリリース」になります。
これまでのところ良いです。
なぜマネージャーが必要なのですか？
コミットフェストの管理
注意深い読者は、パッチの作成者、レビュー担当者、コミッターの3つのグループがプロセスに関与していることに気付いたかもしれません。これらの3つのグループの間には多くの重複があり、そこから問題が始まります。優れたコードレベルのレビューを行うには、人々はコードを理解する必要があり、そうする人々も独自のパッチを作成しています。一方、コミッターは、コードの「問題」を見つけて修正する能力が高いと思われるレビュー担当者にすぎません。コミッターも常に独自のパッチを作成しています。
問題は、パッチの作成者が自分のパッチのみを使用して作業を続けると、他の人のパッチを確認したりコミットしたりする時間がなくなることです。これは、フィードバックを受け取り、すぐに別のバージョンで作業してフィードバックを増やすと、簡単に発生する可能性があります。これにより、非常に長く続く可能性のあるループが作成されます。ある時点で、作成者がcommitfestからパッチを削除し、他の誰かのパッチのレビューに取り組むのが公正なことです。しかし、パッチが非常に重要であると誰もが信じているため、これが自然発生的に発生することはめったにありません。
ここで、commitfestマネージャーが登場します。 1つのタスクは、pgsqlハッカーの人々から実際にパッチをレビューすることに関心を集めることです。ほとんどの場合、グループに公開メールを送信するだけで、人々はパッチについて読んだり、話し合ったり、テストしたり、考えたりすることができます。多くの場合、パッチの作成者は、自分のパッチだけでなく、他の人のパッチを確認する必要があることを思い出させる必要があります。 commitfestアプリケーションには、そのために使用できる便利な電子メール送信インターフェイスがあります。これらは通常、十分な量のクロスレビューを作成するのに十分です。
古い、ほとんど忘れられているルールがあります。パッチの作成者がレビューを行わない場合、パッチはそれ以上の考慮なしにcommitfestから閉じることができます。私の知る限り、これは一度も起こったことがなく、少なくともある程度はパッチの作成者が「善良な市民」であると述べています。
したがって、説得であれ強制であれ、commitfestマネージャーは、ハッカーがすでに協力している場合を除いて、ほとんどの場合自発的に発生しないパッチを人々にレビューさせることができます。
一方、パッチの作成者は、パッチを更新せずにそのままにしておくことがあります。考えられる答えの1つは、単に「フィードバックとともに返される」ものを閉じることですが、ほとんどの場合、作成者に更新バージョンの提出を促す価値があります。
commitfestマネージャーは、独自のレビューを行うためにかなりの時間を費やすこともできます。また、コミット権限がある場合は、パッチをコミットすることもできます。
最後に、commitfestが終了したときにすべてのパッチが閉じられるようにするのは、commitfestマネージャーの責任です。これは、通常、開始から1か月後になります。フィードバックを受け取ったパッチについては、作成者が別のバージョンで応答した場合、「パッチを次のcommitfestに移動する」のが妥当です。commitfestの（フィードバックを提供する）約束は守られています。ただし、フィードバックを受け取っていないパッチに対してこれを行うのは不公平です。それが起こると、commitfestsを閉じるのがより難しくなります。
2016年1月のcommitfest
このグラフは、2016年1月のcommitfestを示しています。データは、私が送信した毎週のステータスメールからのものです：開始、第1週、第2週、第3週、第4週、フィナーレ。
「レビューが必要」または「コミッターの準備ができました」ステータスの85から始めたことがわかります。これは、作成者以外の誰かが行動するのを待っていたことを意味します。 1週間後、これらのステータスのパッチは71になりました。つまり、1週間で14のパッチが処理されました。これは、持続した場合、パッチキュー全体があと5週間で終了することを意味するため悪くありません。
しかし、その最初の週に、私は6つの些細なパッチをコミットしました。それらはすぐに使い果たされ、コミット率は低下すると予想されます。幸いなことに、他のコミッターは一生懸命働いており、コミットされたパッチの割合は全期間を通じてほぼ一定であったことがわかります。コミッターに適切な説得が適用されていれば、すべてのコミッターでこれを達成できる可能性があります。
「フィードバック付きで返送」ステータスは、commitfestの最後にのみ表示されたことがわかります。これは、「作成者を待っている」行に見られる傾向をほぼ継続しています。私の意見では、これは大丈夫です。一部の人々は、特定のパッチを早い段階で「起動」することを好むため、実際に侵入する可能性のあるパッチ（トリアージ）に焦点が当てられます。自分でそれについてはよくわからないので、ここではその考えを適用しませんでした。
このcommitfestは、パッチをコミットするのに適度に成功したと思います。その前線での進歩は、必ずしも巨大ではないにしても、確かに目に見えました。また、すべてのパッチ作成者がパッチについてかなりの量の議論を行うことを確実にすることに大いに成功したと思います。ですから、私としては、完了した仕事に満足しています。
将来のcommitfestマネージャーへのアドバイス
毎週ステータスを更新すると、良い結果が得られると思います。何かが起こっているという印象を全員に与え、レビュー担当者とコミッターの両方が仕事をするように動機付けます。
また、毎回注意が必要ないくつかのパッチをリストするというアプローチを取りました。毎回同じパッチではなく、毎回異なるセットに焦点を合わせて、すべての停止したパッチがどこかでキックされるようにしました。これは微妙な作業です。注意が必要なすべてのパッチをリストする方が簡単ですが、そうすると、目が巨大なリストに釉薬をかけ、すべてが無視され続けます。
commitfestがどのように管理されたかについてのご意見をいただければ幸いです。コメントとして公開したくない場合は、私にメールしてください。私がしたことは効果がなかったと思う場合、または何をすべきかについて他のアイデアがある場合は、喜んで耳を傾けます。将来的には、リソースが許す限り、他のコミットフェストを管理する可能性があります。
最後に、2016年3月に開催されるcommitfestに備えましょう。 9.6の最後のコミットフェストになる予定で、みんなのためにやることがたくさんあると確信しています。パッチレビューをお楽しみください！