PostgreSQLの開発プロセス
Bruce Momjian
PostgreSQL 開発コアメンバ / EnterpriseDB
概要
PostgreSQLの開発プロセスは、他の典型的なオープンソースプロジェクトと同様な部分もある一方で、信頼性の高いデータベースシステムを開発する上での複雑な要求に答えるために、異なっている部分もあります。本稿では、PostgreSQLの開発モデルを議論し、この開発プロセスが採用されている理由を説明します。
はじめに
1996年以来、PostgreSQLを開発するボランティアは増え続けています。世界中の非常に優秀なデータベース開発者が、インターネットを使って連絡をとりながら、このもっとも進歩したオープンソースデータベースを作っています。
従来の開発チームのやり方とは異なっているため、PostgreSQLコミュニティによる開発プロセスは分かりにくいところがあります。例えば、すべてを統括する権威者がいない、バグトラッキングシステムがない、開発におけるロードマップがない、リリース日が定められていない、といった点です。オープンソースプロジェクトであるがゆえに自然とそうなっているところもあれば、形式ばらない開発組織ではその方が効率的で現実的だ、という理由でそうなっているところもあります。
すべてを統括する権威者がいない
PostgreSQL開発の中には、特定の権威者はいません。その代り、すべての議論は開発者向のメーリングリストで行なわれ、誰でも自分の意見を表明できます。ですので、より多くの人が、複雑な議論に参加できます。この方法では2つの利点が出てきます。まず、ある話題について熟知した開発者が、専門知識を提供できるということ。次に、新たにプロジェクトに参加する人にとって敷居が下がり、彼らもプロジェクトに参加している、という意識を持てるようになる、ということがあります。主力開発者が持ち合わせていない洞察や経験を持っているが故に、プロジェクトにそれほど深く関わっていないの方が、むしろ難しい意思決定の際に影響力を及ぼす、という結構よくあることです。
バグトラッキングシステムの欠如
PostgreSQLはバグトラッキングシステムを採用していません。通常、大きな開発プロジェクトではバグトラッキングシステムが使われます。ユーザはバグトラッキングシステムにバグレポートを送信し、バグトラッキングシステムの管理者はバグレポートを吟味して誤ったバグレポートを削除し、それぞれのバグ項目に開発者を割り当てます。最悪の場合、バグトラッキングシステムにはバグレポートが記録されるものの、めったに解決されないゴミ捨て場になってしまいます。
PostgreSQLでは、メーリングリストを通じてバグレポートを収集しているので、バグトラッキングシステムの管理者の仕事はメーリングリストの講読者の間に分散されます。報告されるバグのうち、実際にバグであるものの割合は小さいので、メーリングリストの講読者はバグの報告者と協力しながら、報告されたデータベースの振る舞いを分析できます。明白なバグは経験の深い開発者の目に止りやすく、修正されるかTODOリストに追加されます。
開発ロードマップがない
資金を持たないコミュニティプロジェクトでは、開発パワーを確実に割り当てることはできません。開発チームは、開発者にある項目を担当するように働き掛けることはできますが、開発項目の選択権はプロジェクトに自分の時間を割いている開発者や、開発スポンサーになっている雇用者の意思に左右されます。開発ロードマップがないので、ユーザの要求の変化に応じて、柔軟に要件を変えることができます。
開発に関する議論は、主にhackersメーリングリストで、電子メールによって行なわれます。このメーリングリストには、機能に関する議論、パッチのレビュー、バグ修正に関して、1日あたり約85通の投稿があります。ソースコードのリポジトリはCVSで管理されています。約15人の人が、更に多くの人から投稿されるパッチを日々処理しています。
リリース日が決まっていない
信頼性のないデータベースは使い物になりません。主要な開発者たちは、12から14ヶ月ごとにメジャーリリースを行ないたいと思っていますが、それはコードの信頼性が、十分リリース出来る程度になっているかどうかにかかっています。
開発プロセス
日々の開発では、たぶん10人くらいの、経験が長く、大きな機能の開発を行なっている貢献者が議論を行ないつつ、一方で、はじめてパッチを投稿した数人の貢献者がレビューを待っていて、さらには数十のバグレポートが、チェックされ、修正されるかTODOリストに追加されるのを待っている、というふうに進んでいます。
2ヶ月ごとに、コミットフェスタでまだ適用されていないパッチが処理されます。通常コミットフェスタは1ヶ月続きます。だいたい9ヶ月でコミットフェスタは終了し、未解決の問題が収集され、メジャーバージョンの最初のベータ版までには解決されます。十分バグがなくなり、リリース候補版 (release candidate) が作られるまでには、通常数回のベータリリースが行なわれます。リリース候補版がフィールドから良いテスト結果を得られれば、最終リリース版が作成され、数週間後には次の開発プロセスが再び始まります。
開発者をサポートするツール
複雑なデータベースのソースコートでは、リグレッションテストだけでは十分にバグを取りきれません。それよりも、そのパッチが新たなバグを付け加えるのではなく、確かにバグを修正することを確認するための主たる方法がパッチレビューだと言えます。
コードを管理可能かつ信頼性のあるものにしていくためのツールがいくつかあります。PostgreSQLビルドファームにより、可搬性がなく、修正する必要のあるコードが検出されます。コードのインデント (字下げ) の一貫性を保つ開発者向けのツールがあります。新しく開発に参加する人を助ける多くのドキュメントがあります。開発者FAQから始めるのが一番良いでしょう。
新しい開発者
PostgreSQLの開発プロセスでは、新しく開発に参加する人は、SQL標準へ厳密に準拠しなければならないこと、コードが明確で信頼できるものであることへの要求にしばしばいらだちを覚えるものです。1996年、PostgreSQL開発者は、10年もののコードベースを、カリフォルニア大学バークレー校から引き継ぎました。成熟したコードベースを引き継いだことで、長期間にわたってコードを保守するためのこれらので要件を守っていくことが更に重要になりました。大半の開発組織と違って、PostgreSQL開発者は、今日行なった作業による目先の効果よりも、今後何年もの間データベースシステムに与える影響の方が重要だと考えています。
まとめ
PostgreSQLの開発プロセスの一部は、他のオープンソースプロジェクと同様ですが、他の点では、信頼性に関する要求、長期間にわたるコードの保守、データベースソフトの複雑さにより、独特なものになっています。新しく開発に参加する人の中には、PostgreSQLの開発プロセスにとまどいを覚える人もいるかもしれませんが、実際にはこの方法はうまくいっており、多くの人は15年に渡って発展してきた開発のやり方を高く評価するようになっています。