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

問題を報告する ソースを表示 夜間 7.4 をタップします。 7.3 7.2 7.1 7.0 6.5

このガイドは、Bazel オープンソース プロジェクトのメンテナンス担当者を対象としています。

Bazel への貢献を検討している場合は、Google Cloud の構築への貢献に関する Bazel を使用してください。

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

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

Bazel のコアコントリビューター グループには、 さまざまな役割を担います。具体的には、次のとおりです。

  • リリース プロセス: Bazel のリリース プロセスを管理します。
  • グリーンチーム: ルールとツールの健全なエコシステムを成長させる。
  • デベロッパー エクスペリエンス ガーデナー: 外部貢献を奨励し、レビューを行う 開発ワークフローをよりオープンなものにしました

リリース

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

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

問題のライフサイクル

  1. ユーザーが問題テンプレートを使用して問題を作成すると、未確認のオープンな問題のプールに追加されます。
  2. デベロッパー エクスペリエンス（DevEx）サブチームのローテーション メンバーが問題を確認します。
    1. 問題がバグ以外でも機能リクエストでもない場合、DevEx メンバーは 通常、この問題はクローズされ、ユーザーは StackOverflow および Bazel-discuss 用 目に留まりやすくなります
    2. 問題がコミュニティが所有するルール リポジトリ（rules_apple など）に属している場合、DevEx メンバーは適切なリポジトリにこの問題を転送します。
    3. 問題が不明確であるか、情報が不足している場合は、DevEx メンバーは問題をユーザーに割り当て、続行する前に詳細情報をリクエストします。これは通常、お客様が問題 テンプレート。
  3. DevEx メンバーは問題を確認した後、問題に即時の対応が必要かどうかを判断します。ある場合は、P0 を割り当てます。 優先度ラベルとチームリーダーのリストのオーナー。
  4. DevEx メンバーが untriaged ラベルと 1 つのチームを割り当てる ルーティング用のラベル。
  5. DevEx メンバーは、type: bug などの type: ラベルも 1 つだけ割り当てます。 または type: feature request（問題のタイプに応じて異なります）。
  6. プラットフォーム固有の問題の場合、DevEx メンバーは 1 つの platform: ラベルを割り当てます。 たとえば、Mac 固有の問題の場合は platform:apple です。 この段階で、問題は未優先順位付けの をご覧ください。

各 Bazel サブチームは、所有するラベルに基づいてすべての問題をトリアージします。トリアージは、可能であれば できます。サブチームが問題を確認、評価して、 推奨されます。チーム レーベルのオーナーである場合は、こちらのセクションで詳細をご確認ください。

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

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

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

私のチームはラベルを持っています。必要な対策

サブチームは、所有するラベル内のすべての問題を優先度別に分類する必要があります。できれば、週単位で行う必要があります。

問題

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

なお、bazelbuild が 組織に許可することで、ラベルを追加または削除できるようになります。

pull リクエスト

  1. pull リクエストのリストをチームラベルでフィルタする。
  2. オープンな pull リクエストを確認します。
    1. 省略可: 審査を担当するが、適任でない場合は 適切なレビュー担当者を再割り当てしてコードレビューを実施します
  3. pull リクエストの作成者と連携してコードレビューを完了します。
  4. PR を承認します。
  5. すべてのテストに合格することを確認します。
  6. 内部バージョン管理システムにパッチをインポートして、内部 使用します。
  7. 内部パッチを送信します。パッチが正常に送信され、エクスポートされると、PR は GitHub によって自動的にクローズされます。

優先度

メンテナンス担当者は、次の優先度の定義を使用して問題の優先度を判断します。

  • P0 - Bazel リリース（リリース候補版を除く）が使用できなくなる、または Bazel プロジェクトの開発に重大な影響を与えるサービスが停止する、重大な機能の破損。これには、新しいリリースで導入された回帰など、 互換性のない互換性を破る変更が行われた場合、 基準となる 変更 に関するポリシーに準拠する必要があります。実用的な回避策がない。
  • P1 - 重大な欠陥または 次のリリースで対処すべき機能の特定、次のリリースで対処すべき重大な問題など、 （Bazel プロジェクトの開発を含む）多くのユーザーに影響を与えますが、 実用上の回避策が存在します。通常、すぐに対応する必要はありません。イン 今四半期のロードマップで計画されています。
  • P2 - 欠陥または機能 現在は対処していませんが運用時の問題（中程度） リリースされた Bazel バージョンであり、 今後のリリースで対処される予定である、または簡単な回避策が存在する。
  • P3 - 望ましい軽微なバグ わずかな影響で終了できます。Bazel ロードマップで優先されていない コミュニティへの貢献が推奨されます。
  • P4 - 優先度の低い不具合 成約に至る可能性の低い機能リクエストです。開いたままにしておいて 影響を受けるユーザーが増えた場合、優先順位を再設定することができます。
  • ice-box
    • 現在対処する時間がない問題や 寄付を受け付けるまでの時間が長くなります。Google はこれらの問題をクローズし、 作業している人はいませんが 十分な数の人が影響を受けた場合や リソースが必要になります気軽にコメントやリアクションを追加しましょう。 閉じることもできます。

チームラベル

  • team-Android: Android チームの問題 <ph type="x-smartling-placeholder">
  • team-Bazel: Bazel プロダクト / 戦略に関する一般的な問題
  • team-Build-Language: BUILD、.bzl API、Stardoc に関する問題。
  • team-Configurability: 構成可能性チームの問題
  • team-Core: コアチーム向けの問題
  • team-Documentation: ドキュメント チームの問題
  • team-ExternalDeps: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル
  • team-Local-Exec: 実行（ローカル）チームに関する問題 <ph type="x-smartling-placeholder">
  • team-OSS: Bazel OSS チームに関する問題: インストール、リリース プロセス、Bazel のパッケージング、ウェブサイト、ドキュメント インフラストラクチャ <ph type="x-smartling-placeholder">
  • team-Performance: Bazel パフォーマンス チームの問題
  • team-Remote-Exec: 実行（リモート）チームの問題
  • team-Rules-CPP: ネイティブ Apple ルール ロジックなど、C++ ルールに関する問題
  • team-Rules-Java: Java ルールに関する問題 <ph type="x-smartling-placeholder">
  • team-Rules-Python: ネイティブ Python ルールに関する問題
  • team-Rules-Server: Bazel に含まれるサーバーサイド ルールに関する問題 <ph type="x-smartling-placeholder">
  • team-Starlark-integration: API 以外の Bazel + Starlark 統合。Bazel による Starlark インタープリタ、Stardoc、ビルトイン インジェクション、文字エンコードのトリガー方法について説明しています。含まれない: BUILD または .bzl 言語の問題。
  • team-Starlark-interpreter: Starlark インタープリタの問題（java.net.starlark 内のすべて）。BUILD API と .bzl API の問題（Bazel と Starlark との統合）は team-Build-Language にあります。

新しい問題では、チームに代わって category: * ラベルのサポートを終了しました。 できます。

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