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

問題を報告する ソースを表示 Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

このページでは、投稿者が 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 の内部バージョン管理システムに適用します。

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

    内部送信後、パッチは Git commit としてエクスポートされ、その時点で GitHub pull リクエストは閉じられます。最終的な変更はすべてあなたに帰属します。