OSS の開発コミュニティってどんなところ？(4)

パッチを作成する

議論が固まり始めたら，レビューのためのパッチを作成します．パッチは CVS にある開発版のソースに対し，「cvs diff -c」などのコマンドを使い，差分が明確になるようなものを作成します． CVS からの開発版のソースコードの入手方法は，Coding のページ や PostgreSQL に付属するドキュメントに記載されています．

PostgreSQL はほとんどの部分が C 言語で書かれているので，C でコーディングすることが多いと思いますが， PostgreSQL ではインデントなどのコーディングスタイルが厳密に決められています．ソースコード中の src/tool/editors には vi と emacs 用の設定ファイルがあるので，それを利用すると良いでしょう．

ドキュメントパッチも忘れずに

ここで気を付けなければならないのは，プログラムソースに対するパッチだけでなく，ドキュメントも作成しなければならない点です． PostgreSQL では，ドキュメントは SGML で作成し，そこから HTML などを生成する方式を採用しています． SGMLというと敷居が高そうですが，doc/src/sgml にある他のソースを参考にすればさほど難しくないと思います．

テスト

作成したパッチは，少なくとも「リグレッションテスト」に合格させておく必要があります．

リグレッションテストは PostgreSQL のソースコードに付属しているテストスィートで，111 項目，全部で 2 万行を超える SQL 文から構成されており，実際に SQL を実行して期待される結果と比較することによって合否を判定します．(※) このテストは単純に順次 SQL 文を実行するだけでなく，並列実行も含むなかなか厳しいテストですが，データベースシステムでは信頼性は非常に大事で，この程度のテストをパスしないようでは話になりません．

テストの実行は簡単で，単にソースツリーのトップレベルで「make check」と叩くだけです．

【編集註】記事掲載現在の最新バージョン 8.3.4 では、114 項目 (行数は約 24000 行)。

パッチの投稿

作成したパッチは，「pgsql-patches」か，「pgsql-hackers」に投稿します．投稿されたパッチは，誰かが中身を検討し，いろいろコメントがされることでしょう．そのコメントに納得がいかなければ反論し，もっともな意見であればパッチに取り込みます．通常，こうして何回かパッチは手直しをされます．このときの注意点は，「できるだけすばやく」です． CVS のソースはどんどん変更されていきます．議論に対して返信をさぼっていたり，パッチの修正が延び延びになっていたりすると，いつの間にかパッチがあたらなくなったりします．メールのレスポンスは迅速に！

【編集註】現在(2008.11.6)では、作成したパッチは「pgsql-hackers」にのみ投稿するようになっています。また、大きなパッチは コミュニティの Wiki へ登録し、進捗状況や議論の要約が管理されるようになっています。詳しくは Wiki のページ をご覧ください。

パッチの適用

晴れてパッチの内容が合格となれば，後は CVS に適用されるのを待つだけです．パッチがコミットされると，pgsql-committers メーリングリストに自動投稿されるのですぐわかります．

パッチはたくさん投稿されるので，順番待ちになることもあります．このあたりの管理はコアメンバの Bruce Momjian 氏が行っています．あまりにパッチの適用が遅いようであれば，pgsql-hackers で問い合わせてみましょう．

いったんパッチが CVS に適用されれば，あなたの貢献は永遠に記録に残ります．ソースに付属する「HISTORY」というファイルには，誰がどのバージョンにどのような貢献をしたかが簡潔に記録されます（リスト 1）．オープンソースに対する貢献は基本的に無償の行為ですが，唯一の報酬とも言えるのがこの記録でしょう．

リスト 1 ● HISTORY ファイルに書かれる貢献の記録の例

* Add pgrowlocks module (Tatsuo) 

This shows row locking information for a specified table. 

また，この記録はあなたがこの機能におけるエキスパートであることの証明でもあります．ときには海外の見ず知らずの人から直接の問い合わせがあることもあり，海の向こうで誰かがこの機能を使ってくれているのだと思うと，モチベーションの向上にもつながります．

PostgreSQL 開発コミュニティに参加するにあたって

最後に，PostgreSQL 開発コミュニティにこれから参加する方のために，筆者の経験から役に立ちそうなことを書いておきます．

メーリングストを事前に熟読しよう

どんなコミュニティにも，それぞれ独特の雰囲気とか「空気」があります．メーリングリストを事前に熟読することにより，それらを掴むことができますし，そうすればスムーズにコミュニティに溶け込めるでしょう．コミュニティにデビューする前に，少なくとも 3 ヶ月，場合によっては半年くらいはメールを読み続けたほうが良いと思います．

説明を十分に

おそらく平均的な日本人にとって，開発コミュニティに参加する際の最大の障壁は技術ではなくてコミュニケーションです．そのため，ついつい「コードがあればわかりあえる」とばかりに十分な説明なしにソースプログラムを押しつけようとして，コミュニティから受け入れられないことになりがちです．

冒頭書いたように，PostgreSQL のコミュニティは世界中のいろいろな国から参加する人で成り立っています．拙い英語でもかまわないので，きちんと自分のやりたいこと，またなぜそれが必要なのかを明確に説明しましょう．一度では通じないかもしれませんが，何度も説明するうちに必ず道は開けます．

筆者などは，国際化対応のパッチを受け入れてもらうまでに 1 年，国際化対応をデフォルトにしてもらうのにそこからさらに 4 年かかりました．

議論は冷静に

メーリングリストでは，かなり率直な意見を言われることがあります．人によっては「このプログラムはまったく駄目だ」のような言い方をすることもあります．しかし，ここでかっかしてはいけません．卑屈になる必要はまったくありませんが，冷静にどこが駄目なのか，あるいは駄目でないのか，を議論しましょう．必ず実りがあるはずです．自分のプログラムの改良点が見付かれば儲けもの，位のおおらかな気持ちでいきましょう．

PostgreSQL 開発者目指す方のための技術情報

ここまで読んで，PostgreSQL の開発に興味を持たれた方のために，最後に PostgreSQL の内部情報に関するドキュメントを紹介しておきます．

参考資料

1. PostgreSQL ドキュメント「VII. Internals」の章

   システムカタログ，データベースのファイル構造の解説があります．

2. 日本 PostgreSQL ユーザ会の「しくみ分科会」

   PostgreSQL の内部構造について研究会が行われ，その資料が公開されています．

3. 技術評論社の「WEB+DB PRESS」Vol.15 から Vol.31 に筆者が執筆した「徒然 PostgreSQL 散策」

   「PostgreSQL 研究所」の連載中で PostgreSQL の内部構造を取り上げています． PDF ですべての記事が公開されています．

（2008年12月9日公開）