More Related Content
More from NTT DATA OSS Professional Services (20)
![AIシステムのセキュリティ：脅威となりつつあるAIの現状と課題 [English] Security of AI Systems: The Current...](https://cdn.slidesharecdn.com/ss_thumbnails/20241023css2024-250829030738-876ce56e-thumbnail.jpg?width=560&fit=bounds)
PostgreSQLコミュニティに飛び込もう
- 1. Copyright © 2015 NTT DATA Corporation 2015年11月14日 株式会社ＮＴＴデータ 澤田雅彦 PostgreSQLコミュニティに飛び込もう ～ PostgreSQLのパッチをレビュー ～
- 2. 2Copyright © 2015 NTT DATA Corporation はじめに PostgreSQLのコミュニティ開発って、 • 興味はあるけどなんか難しそう。。英語とか。 • 「コミュニティ開発」＝「すごい機能を開発」 と思っていませんか？ 新しい機能を作るだけでなく、パッチのレビュー、typoの修正も一つのコミュニティ開発です。 本日は、PostgreSQLコミュニティにおける「パッチのレビュー方法」についてできるだけ具体的に解 説します。 資料での説明後、実際にパッチをレビューする時間を設けていますので、一緒にやってみましょう。
- 3. 3Copyright © 2015 NTT DATA Corporation はじめに ～レビュアーの仕事とは？～ The eventual committer will do their own review before the patch goes into the code base. The task of a reviewer is to take off load from committers by catching simple problems. The reviewer's job is not necessarily to guarantee some level of quality, but just to report any problems they are able to find. That task is done if you think the patch is ready for in-depth review from a committer. レビューアの仕事は、前もって問題を取り除くことで、コミッタの仕事を減らすことです。 レビューアには完璧を求められることはなく、見つけられるだけの問題を見つけることが仕事 になります。もしあなたが、そのパッチがコミッタの詳細レビューにたる品質になったと判断したら、 そこでレビューは完了します。 https://wiki.postgresql.org/wiki/Reviewing_a_Patch/ja より
- 4. 4Copyright © 2015 NTT DATA Corporation はじめに ～パッチレビューのモチベーション～ パッチをレビューすることで、 • PostgreSQLの最前線に身を置き、最新情報を知れる。 • レビューしたパッチやその周辺機能に(ソースコードレベルで)詳しくなれる。 • 途中の議論も知れるので、なぜその機能が入ったのか？なぜそのような仕様になっ たのか？残課題はあるか？どのような条件でバグが発生するか？など、その機能 (やバグ修正)の知識がより深まる。 • 他人のパッチやコミットされたコードを見ることで、プログラミングスキルが向上する。 (PostgreSQL開発における勘所を学べる) • カンファレンス等でパッチ作成者とコミュニケーションを取りやすくなる。
- 5. 5Copyright © 2015 NTT DATA Corporation ＩＮＤＥＸ PostgreSQL開発サイクル PostgreSQLはどのように開発されている？ Commit Festとは？ PostgreSQLのパッチをレビューをしてみよう パッチレビューに必要なもの パッチレビューのやり方 おすすめパッチ紹介
- 6. Copyright © 2015 NTT DATA Corporation 6 PostgreSQLの開発サイクル
- 7. 7Copyright © 2015 NTT DATA Corporation 2014年度 2015年度 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月 1 月 2 月 3 月 4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月 PostgreSQL開発サイクル CF1 CF2 CF3 CF4 CF5 Feature Freeze Alpha1,2 Beta1 Beta2 RC1Beta3 9.5開発 9.4開発 コミュニティサポート CF1 CF2 CF3 9.6開発 Beta1,2
- 8. 8Copyright © 2015 NTT DATA Corporation Commit Festとは？ • パッチレビューを集中的に行うサイクル • 「パッチ作成：1か月、パッチレビュー：1か月」で1サイクル • 1パッチ、1レビューのルール • パッチはCommit Fest Appで管理 Ready for Committer Needs review Waiting on Author Committed Returned with feedback (次のCFへ。 ただし課題あり。) Rejected (提案却下) Move to next CF (次のCFで引き続きレ ビュー) パッチレビュー中 パッチレビュー完了 パッチクローズ パッチ 修正・投稿 レビュー コミット レビュー 完了 パッチ作成者 レビュアー コミッター CF終了 課題あり 提案却下
- 9. 9Copyright © 2015 NTT DATA Corporation Commit Fest Appの使い方 • アカウントの作成が必要ですので、登録します。 • https://www.postgresql.org/account/signup/ • Commit Fest Appで現在のCFに移動します。 • https://commitfest.postgresql.org/ レビューする パッチを選択 します
- 10. 10Copyright © 2015 NTT DATA Corporation Commit Fest Appの使い方 「Become reviewer」 を押してレビュアーと して登録します
- 11. 11Copyright © 2015 NTT DATA Corporation Commit Fest Appの使い方 パッチのステータス を変えるときはここ
- 12. Copyright © 2015 NTT DATA Corporation 12 PostgreSQLのパッチレビュー
- 13. 13Copyright © 2015 NTT DATA Corporation パッチレビューはコミュニティへの貢献方法の一つ コミュニティへの貢献方法は • 新規機能の開発 • バグ修正 • バグ報告 • パッチのレビュー など様々。 もちろん、 • ソースコード内のコメントのtypo修正 • ドキュメントのtypo修正 もコミュニティへの貢献です。
- 14. 14Copyright © 2015 NTT DATA Corporation コメントのtypo修正もコミュニティへの貢献の一つ
- 15. 15Copyright © 2015 NTT DATA Corporation レビュアーとしてコミットログに
- 16. 16Copyright © 2015 NTT DATA Corporation 必要なもの • 開発環境 • Linux, Windowsどちらでも • PostgreSQLがコンパイル、起動できるように • PostgreSQLのソースコードが見れるように • gitあると便利です (例) Mac + VMFusion(CentOS) + git + emacs • ネット環境 • ソースコードの入手、MLへの投稿で必要 (例) git使うときとメール送るときしかネットを使わないので、テザリング環境でも十分 • メールアドレス • コミュニティで議論するために必要 (例) gmailアカウントを作る • PostgreSQLコミュニティのアカウント • Commit Fest Appで必要 • C言語の知識 • C言語で書かれたソースをレビューするので • 少しの英語力 • 中学生レベルの英語でOK(だと思います)
- 17. 17Copyright © 2015 NTT DATA Corporation メーリングリストへの登録 PostgreSQLコミュニティでのコミュニケーションはメーリングリストが主体です。 登録しておくべきメーリングリストは3つ • pgsql-hackers • [email protected] • 開発、バグ修正関連の議論はここで行われる。パッチレビューコメントを送るのもここ。 • pgsql-committers • [email protected] • コミットされた内容が流れる。何がコミットされたかを知る為に必要。 • pgsql-bugs • [email protected] • バグレポートの内容や、その後の議論がここで行われる。 http://www.postgresql.org/community/lists/subscribe/ から今すぐ登録！
- 18. 18Copyright © 2015 NTT DATA Corporation パッチレビューの流れ レビューコメントを送る パッチをレビューする これまでの議論を追う レビューするパッチを決める
- 19. 19Copyright © 2015 NTT DATA Corporation レビューするパッチを決める 決め方は人それぞれ • 機能、分野別 • プランナ関連、インデックス関連、レプリケーション関連… • contribモジュール別、クライアントアプリケーション別… • 実業務で関連しそうな所 • 自分が興味ある所 • 難易度別 • PostgreSQLのバックエンド機能(プランナ、レプリケーションなど)より、 PostgreSQLのフロントエンド機能(psql, pg_dump、pgbenchなど)の方が、読むコード 量が少ない場合が多く、取り掛かりやすい • 規模別 • 大きい機能をレビューしてみたい！(UPSERT、BRINなど) • 簡単なバグ修正
- 20. 20Copyright © 2015 NTT DATA Corporation 議論を追う 既に議論が進んでいる場合は、これまでの議論をキャッチアップします。 • どんなことを解決する機能なのか？ユースケースは？ • どのようなインタフェースで作られているか？ • 議論の雲行きを見る。 • それまでの議論での合意事項、未合意事項。
- 21. 21Copyright © 2015 NTT DATA Corporation パッチをレビューする レビューのレビュー コーディング・レビュー 性能試験 アーキテクチャ・レビュー 機能テスト 提案・仕様レビュー そのパッチは 本当に必要？ 既存機能との重複 はない？ 仕様通りに動く？ クラッシュしない？ 本当に性能向上する？ 他の機能の性能に影響 を与えてない？ コーディング規約 に沿っている？ 十分なコメントが ある？ 将来問題になりそうな 依存関係がないか？ 他のモジュールと組み 合わせても問題ない か？ レビューアは本来 やるべきことをす べて行ったか？ 参考:https://wiki.postgresql.org/wiki/Reviewing_a_Patch/ja
- 22. 22Copyright © 2015 NTT DATA Corporation Wikiの内容に沿ったレビュー
- 23. 23Copyright © 2015 NTT DATA Corporation (例)よくやるレビューの流れ • パッチをHEADにあててみる • git diff --check • コンパイル • リグレッションテスト(make check-world) • 仕様通り動くか？ • 性能試験 • 思いつくいろんな使い方をしてみる • 境界値テストとかでもOK • すごい大量に実行してみたり、すごい長い文字を入れてみたり • レプリケーション環境でもちゃんと動くか？pg_upgradeしても問題ないか？ など ここまでで何か問題があれば、それを開発者に伝えてあげましょう！
- 24. 24Copyright © 2015 NTT DATA Corporation パッチがHEADに当たらなかった
- 25. 25Copyright © 2015 NTT DATA Corporation 仕様通りに動かなかった
- 26. 26Copyright © 2015 NTT DATA Corporation (例)そして、パッチを見ていく(コードレビュー) • コーディング規約 • インデントはスペースは4つ。コメントの書き方もチェック。 • コーディング規約：http://www.postgresql.org/docs/current/static/source.html • コメント • 適切なコメントが書いてあるか？コメントの更新忘れはないか？ • ドキュメントパッチ • ドキュメントの内容に間違いはないか？typoはない？ • リグレッションテストパッチ • テストすべきテストケースがリグレッションテストにあるか？ • 既存コードの流用 • 既存のコードをうまく利用して作られているか？無駄なコードはないか？ • 環境依存(Windows対応) • Windowsでも動くように。 • レビュアーそれぞれの視点 • 実装方法がいまいちだと思う。この既存機能と衝突しそう。 • ここのロジックはもっとシンプルに実装できそう。
- 27. 27Copyright © 2015 NTT DATA Corporation メールを書くときのポイント • 日本語を書いて英語に訳す？最初から英語で考える？ • 具体的な例を出して説明する • For example … • 他の人が書いている英語のマネをする • 文を無理に長くしなくてもよい • I applied the patch to HEAD. But I got FAILED. … • 箇条書きにする • 分からないことは素直に聞いてみる • PostgreSQLコミュニティの人は優しい人が多い
- 28. 28Copyright © 2015 NTT DATA Corporation レビューコメントを送る 例えば、 Thank you for updating the patch. The followings are my review comments and questions. * pg_stat_vacuum_progress should have the oid of relation begin vacuumed. * progress_message variable in PgBackendStatus is not used at all. IIRC, progress_message variable is set the description of processing. * The progress of VACUUM FULL seems wrong. When I run VACUUM FULL for a table, I got following progress. =# SELECT * FROM pg_stat_vacuum_progress; : : * The vacuum by autovacuum is not displayed. Could you check this on your environment? Regards, -- Masahiko Sawada
- 29. 29Copyright © 2015 NTT DATA Corporation いざ、レビューコメントを送信 • 返信は必ずpgsql-hackersをTOに入れる。(作成者個人宛てに送らない) • 議論の途中であれば、議論に参加している他の開発者もTOまたはCCに入れる。 • 基本「reply all」で問題なし。 • メールを送ったら、パッチのステータスを「Waiting on Author」に変更 ここから本当のコミュニティ活動が始まります。 議論→レビューを繰り返し、自分が満足いくまでレビューをしましょう。 また、必要に応じて議論にも参加しましょう！ 「”Ready for Committer” is reviewer saying, “Based on my review, I would have committed this if I had been the patch’s committer.”」
- 30. 30Copyright © 2015 NTT DATA Corporation 最後に • CF3はすでに始まっています！ • 約100個のパッチが登録 • その中で「Needs review」は約半数(本日時点) • ちなみに、FreezeMap(PageInfoMap)パッチをレビューしてくれるかた募集中です！ • これまでの議論の経緯、パッチの説明、全部します。
- 31. Copyright © 2011 NTT DATA Corporation Copyright © 2015 NTT DATA Corporation
- 32. 32Copyright © 2015 NTT DATA Corporation (参考) パッチをあてる、リグレッションテストまでのコマンド例 • 開発版のソースコードを入手 • $ git clone git://git.postgresql.org/git/postgresql.git ※既に開発版を入手している場合は、「$ git pull origin master」等で最新にします。 • パッチをHEADにあててみる • $ cd postgresql • $ patch -p1 < <パッチへのパス> または、 • $ git apply <パッチへのパス> ※patchコマンドではあてられるHUNKは全て実際に変更を加えるのに対し、git applyではHUNKが1つでもあたらない場 合に、パッチ全体の適用をやめます(つまり、git applyではパッチの適用がアトミック) • git diff --check • $ git diff --check ※ソースコード末尾に空白等がある場合に検知できます。 • コンパイル • $ make -j 4 > /dev/null ※こうするとコンパイルWARNINGが出た時だけわかります。ただし、 In file included from gram.y:13990: scan.c: In function ‘yy_try_NUL_trans’: scan.c:10192: 警告: unused variable ‘yyg’ は、いつも出るWARNINGなので無視します。 • リグレッションテスト(make check-world) • $ make check-world | tee /tmp/check-world.log • $ less /tmp/check-world.log ※make check-worldの結果を目で確認しつつ、ログを「FAILED」でgrepします。