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

ナイトリー · 9.0 · 8.5 · 8.4 · 8.3 · 8.2 · 7.7

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

Bazel への貢献をご希望の場合は、代わりに Bazel への貢献をご覧ください。

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

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

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

  • リリース プロセス: Bazel のリリース プロセスを管理します。
  • Green Team: Bazel CI の健全性をモニタリングし、破損を報告します。
  • Developer Experience Gardeners: 外部からの貢献を促し、問題とプルリクエストをレビューし、開発ワークフローをよりオープンにします。

リリース

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

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

問題のライフサイクル

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

各 Bazel サブチームは、所有するラベルのすべての問題をトリアージします。できれば毎週行うことが望ましいです。サブチームが問題を審査して評価し、可能であれば解決策を提供します。チームラベルのオーナーの場合は、こちらのセクション をご覧ください。

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

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

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

チームがラベルを所有している。必要な対策

サブチームは、所有するラベルのすべての問題をトリアージする必要があります（できれば毎週）。

問題

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

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

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 がユーザーの返信を長時間待機しており、投稿者が返信していない場合、PR は 30 日後に自動的に古いものとしてマークされ、さらに 30 日後にクローズされます。

    PR をクローズする際は、丁寧な言葉でクローズの理由を説明してください。

優先度

優先度の定義は、メンテナーが問題をトリアージするために使用します。

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

チームラベル

  • team-Android: Android チームの問題
  • team-Bazel: Bazel の一般的なプロダクト/戦略に関する問題
  • team-CLI: コンソール UI
  • team-Configurability: 構成可能性チームの問題。含まれるもの: コアビルド構成と移行システム。含まれないもの: 新しいフラグまたは既存のフラグの変更
  • team-Core: Skyframe、bazel クエリ、BEP、オプション解析、bazelrc
  • team-Documentation: ドキュメント チームの問題
  • team-ExternalDeps: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル
  • team-Loading-API: BUILD ファイルとマクロの処理: ラベル、package()、visibility、glob
  • team-Local-Exec: 実行（ローカル）チームの問題
  • team-OSS: Bazel OSS チームの問題: インストール、リリース プロセス、Bazel パッケージング、ウェブサイト、ドキュメント インフラストラクチャ
  • team-Performance: Bazel パフォーマンス チームの問題
  • team-Remote-Exec: Execution（Remote）チームの問題
  • team-Rules-API: ルール/アスペクト（プロバイダ、runfile、アクション、アーティファクト）を記述するための API
  • team-Rules-CPP / team-Rules-ObjC: ネイティブの Apple ルール ロジックを含む、C++/Objective-C ルールの問題
  • team-Rules-Java: Java ルールの問題
  • team-Rules-Python: ネイティブ Python ルールに関する問題
  • team-Rules-Server: Bazel に含まれるサーバーサイド ルールの問題
  • team-Starlark-Integration: 非 API の Bazel + Starlark 統合。Bazel が Starlark インタープリタをトリガーする方法、Stardoc、組み込みの挿入、文字エンコードなどについて説明します。BUILD または .bzl 言語の問題は含まれません。
  • team-Starlark-Interpreter: Starlark インタープリタの問題（java.net.starlark のすべてのもの）。BUILD と .bzl API の問題（Bazel と Starlark の統合を表す）は team-Build-Language に入れます。

新しい問題については、チームラベルを優先して category: * ラベルを非推奨にしました。

ラベルの全リストについては、こちらをご覧ください。