PostgreSQL へのパッチの送り方

なぜパッチを書くか?

バグを見つけた場合はそれを修正するためなど。
単純にプロジェクトに貢献したいのであれば、Todo - PostgreSQL Wiki を見て自分ができそうなものを選ぶ。
要求仕様が分からない場合は過去ログを検索する、それでも分からないときは Hackers ML で質問する。

パッチを書く

PostgreSQL コーディング規約に従って、パッチを書く。基本的には自分が手を入れている周辺のコードと同じような体裁に整えれば良いと思う。

  • 4 カラム Tab(space に展開されない)
  • レイアウトは BSD 規約
  • C++ の // コメントは使わない
  • 正しいスペル

など。他にもたくさん。

ライセンス

PostgreSQLBSD ライセンスなのでパッチもそれに準ずる。

テストする

src/test にテストがある。自分が書いたコードが既存の機能を壊していないかだけでもテストする。
make check でテストが走る。

パッチを作成する

詳細は Submitting a Patch - PostgreSQL Wiki
Context diff が好まれる。

% cvs diff -c > パッチ名

のように cvs HEAD との差分を取る。

メールを書く

パッチを添付したメールを書く。メールに含めるべきは情報は

  • プロジェクト名
  • ファイル名に v1-v24 のバージョン(パッチは複数回やりとりがあるのでその度にバージョンをあげていく)
  • パッチが何をするものか。短くまとめる。
  • 議論用のパッチなのか、適用して欲しいパッチなのか。
  • patch がどの CVS ブランチのものか?通常は HEAD。
  • コンパイルできているか、テストが通っているか。
  • プラットフォーム依存のものが含まれているか?含まれているなら他のプラットフォームでテストしたか?
  • 新しい機能の場合は例ともにドキュメント。
  • パッチがパフォーマンスに与える影響
  • どうしてその方法をとったか?
  • Todo item に対する patch であれば、その Todo 正確な名前。

など。
書いたメールは PostgreSQL Hackers に送る。

レビューを受ける

レビューが返ってきたら、さらにパッチに磨きをかける。最終的にコミットしてもらえるとうれしい。

CommitFest に追記する

CommitFest というのは、2ヶ月にごとに1度にパッチのキューをさばくための仕組み。
メールを投稿後、ここに追記する必要がある。
http://wiki.postgresql.org/wiki/CommitFestOpen

まとめ

  1. パッチを書く
  2. 整える
  3. 必要な情報を添えてメールを書く
  4. CommitFest に登録する
  5. レビューを受けて修正する
  6. コミットされる(かも)