Pull-Request の取扱いについて定める。なお、Pull-Request には Issue ハンドリングポリシも適用される (ここでは Pull-Request に特有の事項を述べる)。
Pull-Request はレビュアー(各領域の担当者 1 名の LGTM コメントをもってマージ可能とする (設定されたマイルストーンに合わせた時期にマージする)。
レビュアーの判断で以下のいずれかを選択する。
マージを行う (LGTM)
マージを行った後、レビュアーの責任で修正する (LGTM)
Pull-Request の提出者に修正を依頼する
機能性に問題がある、単体テストが含まれていないなどの場合
リジェクトする。
全体戦略、第三者権利の侵害など、改善が見込めない場合
全体
全体の戦略/方針に照らして、必要な機能であるか
コミットログが適切か (issueの場合は番号が #NN 形式で入っていること)
pull-request 先のブランチは適切か
第三者権利の侵害はないか
品質
ミニマムの configure オプションで、ビルドと単体テストに成功する
コーディングスタイルが適切である (./waf cpplint の結果を確認する)
ソース全体から見て、整合性がとれているか
単体テストが含まれている (変更内容に追従している) かつ、カバレッジが十分 (試験の条件設定が妥当) であるか
機械学習アルゴリズムへの修正については、一般的にベンチマークに用いられるデータセット(少なくとも1例)を用いて分散環境に適用した場合に、性能(精度)が同等または向上していることが、実験的に示されていること。
個別観点 (注1)
データ構造を追加する場合は、シリアライザ宣言に漏れがない
clear 系のメソッドは必要なインスタンスフィールドを全て消去している
driver 内で weight_manager の設定漏れがない
./waf install でインストールされるヘッダに Jubatus 独自のマクロが含まれていない
Travis CI
フルセットの configure オプションで、ビルドと単体テストに成功する
コミッタ向け: Pull-Request と直接 commit の使い分け
変更内容が自明である (または Issue 上の議論で収束している) 場合は直接コミットしてよい (レビューが欲しければ pull-request してもよい)。
ただし、ファイルの追加/削除を伴う場合は pull-request によるレビューを必須とする。
(注1) 個別観点は、各リリースで行う振り返りのプロセスから適宜抽出して追加することで、発生しがちな問題を共有して再発を防止する。cf. Scalaのレビュー観点 , Hadoopのレビュー観点
こちらは、マクロ = wscript で定義される定数(HAVE_ZOOKEEPER_H など)というニュアンスでした(現状守れていると思っています)。文言を直します。