Bazel メンテナンス担当者向けガイド

Nightly · 9.0 · 8.6 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

これは、Bazel オープンソース プロジェクトのメンテナー向けのガイドです。

Bazel への貢献をお考えの場合は、Contributing to Bazel をご覧ください。

このページの目的は次のとおりです。

  1. プロジェクトの貢献 プロセスのメンテナーの信頼できる情報源として機能する。
  2. コミュニティのコントリビューターとプロジェクトの メンテナーの間で期待値を設定する。

Bazel の コア コントリビューター グループには、オープンソース プロジェクトの側面を管理するための専用の サブチームがあります。それらは以下のとおりです。

  • リリース プロセス: Bazel のリリース プロセスを管理します。
  • グリーン チーム: Bazel CI の健全性をモニタリングし、破損を報告します。
  • デベロッパー エクスペリエンス ガーデナー: 外部からの貢献を促進し、 問題と pull リクエストを確認し、開発ワークフローをよりオープンにします。

リリース

継続的インテグレーション

bazelbuild/continuous-integration リポジトリで、グリーン チームによる Bazel の CI インフラストラクチャのガイドをご覧ください。

問題のライフサイクル

  1. ユーザーが 問題テンプレートのいずれかを選択して問題を作成すると、 未審査のオープンな 問題のプールに入ります。
  2. デベロッパー エクスペリエンス（DevEx）サブチームのローテーションのメンバーが 問題を確認します。
    1. 問題がバグや機能リクエストでない場合、通常、DevEx メンバーは問題をクローズし、質問の可視性を高めるためにユーザーを StackOverflowと bazel-discussにリダイレクトします。
    2. 問題が rules_appleなどのコミュニティが所有するルール リポジトリのいずれかに属する場合、DevEx メンバーはこの問題を 正しいリポジトリに転送します。
    3. 問題が曖昧な場合や情報が不足している場合、DevEx メンバーは 続行する前に、追加情報をリクエストするために問題をユーザーに割り当てます。これは通常、ユーザーが適切な 問題テンプレート {: .external} を選択していない場合や、情報が不完全な場合に発生します。
  3. 問題を確認した後、DevEx メンバーは問題に 早急な対応が必要かどうかを判断します。必要な場合は、P0 優先度ラベルと、チームリーダーのリストからオーナーを割り当てます。
  4. DevEx メンバーは、ルーティング用に untriaged ラベルと 1 つの チーム ラベルを割り当てます。
  5. また、DevEx メンバーは、問題のタイプに応じて、type: bug や type: feature request などの type: ラベルを 1 つだけ割り当てます。
  6. プラットフォーム固有の問題の場合、DevEx メンバーは、Mac 固有の問題の場合は platform:apple など、platform: ラベルを 1 つ割り当てます。
  7. 問題の優先度が低く、新しいコミュニティ コントリビューターが対応できる場合は、DevEx メンバーが good first issue ラベルを割り当てます。 この段階で、問題は未トリアージのオープンな 問題のプールに入ります。

各 Bazel サブチームは、所有するラベルのすべての問題を、できれば週に 1 回 、優先順位付けします。サブチームは問題を確認して評価し、可能であれば 解決策を提供します。チームラベルのオーナーの場合は、こちらのセクション をご覧ください。

問題が解決したら、クローズできます。

pull リクエストのライフサイクル

  1. ユーザーが pull リクエストを作成します。
  2. Bazel チームのメンバーで、自分の領域に対して PR を送信する場合は、 チームラベルの割り当てと最適な レビュー担当者の選定を担当します。
  3. それ以外の場合は、毎日の優先順位付けで、DevEx メンバーがルーティング用に 1 つの チームラベルとチームのテクニカル リード（TL）を割り当てます。
    1. TL は、PR のレビュー担当者を任意で割り当てることができます。
  4. 割り当てられたレビュー担当者は PR を確認し、承認または削除されるまで作成者と協力します。
  5. 承認された場合、レビュー担当者は PR の commit を Google の 内部バージョン管理システムにインポートして、さらにテストを行います。Bazel は Google 社内で使用されているものと同じビルド システムであるため、すべての PR commit を内部テストスイートに対してテストする必要があります。これが、PR を直接マージしない理由です。
  6. インポートされた commit がすべての内部テストに合格すると、commit はスクイーズされ GitHub にエクスポートされます。
  7. commit が master にマージされると、GitHub は PR を自動的にクローズします。

チームがラベルを所有しています。どうすればよいですか？

サブチームは、所有するラベルのすべての問題を、 できれば週に 1 回、優先順位付けする必要があります。

問題

  1. チームラベルと untriaged ラベルで問題のリストをフィルタします。
  2. 問題を確認します。
  3. 優先度を特定してラベルを割り当てます。
    1. 問題が P0 の場合、DevEx サブチームによって優先順位が付けられている可能性があります。必要に応じて優先順位を付け直してください。
    2. 各問題には、優先度ラベルが 1 つだけ必要です。問題が P0 または P1 の場合は、対応中であると想定されます。
  4. untriaged ラベルを削除します。

ラベルを追加または削除するには、bazelbuild organization に属している必要があります。

pull リクエスト

pull リクエスト（PR）は、外部のコントリビューターが Bazel に価値を追加する主な方法です。オープンソース プロジェクトとして、PR が タイムリーかつ効率的にレビューされ、処理されるようにすることが重要です。

  • 優先順位付け

    awaiting-review ラベルとチーム ラベルが付いた受信 PR を定期的に確認します。これは、ローテーションまたは定期的な優先順位付け会議で行うことができます。 各 PR には 7 営業日以内に最初のレスポンスが届く予定です。

  • レスポンス

    • PR に問題がない場合は、承認して awaiting-PR-merge ラベルを適用します。gTech チームが PR を CL としてインポートします。
    • それ以外の場合は、フィードバックを残して、awaiting-review ラベル awaiting-user-response ラベルに置き換えます。PR の作成者が返信した場合、DevEx サブチームはラベルを 定期的に更新します。
    • 大幅な変更がある PR の場合は、設計ドキュメントまたは 問題での事前ディスカッションをリクエストすることを検討してください。

  • クローズ

    リソースが限られているため、Bazel の標準を満たしていない PR や、レビューまたは維持する能力がない PR はクローズすることが重要です。

    • PR が Bazel の目標に沿っていない場合は、 説明を添えてクローズします。
    • PR が大きすぎて複雑な場合は、分割して小さくするようリクエストしてクローズします。
    • PR のコード品質が標準を満たしていない場合は、説明を添えてクローズします。
    • コードの今後のメンテナンス費用が高すぎる場合は、 説明を添えてクローズします。
    • PR がユーザーのレスポンスを長時間待っていて、 コントリビューターが返信していない場合、PR は自動的に 30 日後に古いとマークされ、さらに 30 日後にクローズされます。

    PR をクローズするときは、丁寧に対応し、クローズの理由を説明してください。

優先度

メンテナーは、次の優先度の定義を使用して問題の優先順位付けを行います 。

  • P0 - Bazel リリース（リリース候補を除く）が使用できなくなる重大な機能の破損、または Bazel プロジェクトの開発に深刻な影響を与えるサービス停止。これには、多数のユーザーをブロックする新しいリリースで導入された回帰や、 破壊的変更ポリシーに準拠していない互換性のない破壊的変更が含まれます。実用的な回避策はありません。
  • P1 - 次のリリースで対応する必要がある重大な欠陥または 機能、または多くのユーザー（Bazel プロジェクトの開発を含む）に影響を与える重大な問題ですが、実用的な回避策が存在します。通常、早急な対応は必要ありません。需要が高く、今四半期のロードマップで計画されています。
  • P2 - 対応する必要がある欠陥または機能 ですが、現在対応していません。リリースされた Bazel バージョンで、ユーザーにとって不便な中程度のライブ問題 。今後のリリースで対応する必要があるか、簡単な回避策が存在します 。
  • P3 - 影響の小さい望ましい軽微なバグ 修正または機能強化。Bazel のロードマップや 今後のリリースでは優先されませんが、コミュニティからの貢献は歓迎します。
  • P4 - 優先度の低い欠陥 またはクローズされる可能性の低い機能リクエスト。より多くのユーザーに影響する場合は、 優先順位を再設定するためにオープンにしておくこともできます。

チームラベル

新しい問題については、category: * ラベルは非推奨となり、チーム ラベルが推奨されています。

ラベルの完全なリストはこちらをご覧ください。