パッチの受け入れプロセス

7.3 · 7.2 · 7.1 · 7.0 · 6.5

このページでは、コントリビューターが Bazel コードベースに変更を提案して変更を加える方法について概説します。

  1. Bazel コントリビューション ポリシーを確認します。
  2. GitHub の問題を作成して、計画と設計について話し合います。動作を変更または追加するプルリクエストには、追跡用の対応する問題が必要です。
  3. 大幅な変更を提案する場合は、設計ドキュメントを作成します。
  4. 投稿者ライセンス契約に署名していることを確認します。
  5. 機能を実装する git コミットを準備します。テストを追加してドキュメントを更新してください。変更がユーザーに目に見える影響を与える場合は、リリースノートを追加してください。互換性のない変更の場合は、互換性を損なう変更をロールアウトするためのガイドをご覧ください。
  6. GitHub で pull リクエストを作成します。GitHub を初めて使用する場合は、プル リクエストについてをご覧ください。メインの Bazel リポジトリでブランチを作成する権限は制限されているため、リポジトリの独自のフォークに commit を push する必要があります。
  7. Bazel のメンテナンス担当者が 2 営業日以内(米国とドイツの祝日を除く)に審査担当者を割り当てます。その期間中に審査担当者が割り当てられなかった場合は、bazel-discuss@googlegroups.com にメールを送信して審査担当者をリクエストできます。
  8. レビュー担当者と協力してコードレビューを実施します。変更ごとに新しい commit を作成して push し、pull リクエストに変更を加えます。審査に時間がかかりすぎる場合(審査担当者から返信がない場合など)は、bazel-discuss@googlegroups.com にメールを送信してください。
  9. 審査が完了すると、Bazel のメンテナンス担当者がパッチを Google の内部バージョン管理システムに適用します。

    これにより、内部の presubmit チェックがトリガーされ、さらなる変更を提案する場合があります。優先度を指定していない場合、変更を送信するメンテナンス担当者は、設計に影響しない「些細な」変更(リンティングなど)を追加します。より深い変更が必要な場合や、変更を直接適用する場合は、レビュー担当者とレビューコメントで好みを伝える必要があります。

    内部送信後、パッチは Git commit としてエクスポートされ、GitHub pull リクエストがクローズされます。最終的な変更はすべてあなたに帰属します。