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

問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

Bazel へのコントリビューションについては、Google Cloud プロダクトへの貢献 Bazel を使用してください。

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

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

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

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

リリース

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

Green チームの Bazel の CI インフラストラクチャガイドを読む bazelbuild/continuous-integration できます。

問題のライフサイクル

  1. ユーザーが 問題テンプレート 未審査の営業待ちのプールに入り をご覧ください。
  2. Developer Experience（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: ラベルも 1 つだけ割り当てます。 または type: feature request（問題のタイプに応じて異なります）。
  6. プラットフォーム固有の問題の場合、DevEx メンバーは 1 つの platform: ラベルを割り当てます。 たとえば、Mac 固有の問題の場合は platform:apple です。
  7. 問題の優先順位が低く、新しいコミュニティで対応できる場合 投稿者の場合、DevEx メンバーは good first issue ラベルを割り当てます。 この段階で、問題は未優先順位付けの をご覧ください。

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

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

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

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

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

サブチームは、担当するラベルのすべての問題を分類する必要があります。 できれば毎週。

問題

  1. 問題のリストをチームラベルと untriaged ラベルでフィルタします。
  2. 問題を確認します。
  3. 優先度を特定してラベルを割り当てます。
    1. DevEx サブチームによってこの問題の優先順位付けがすでになされている可能性があります。 P0.必要に応じて優先順位を変更します。
    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 チームの問題
  • team-Bazel: Bazel プロダクト/戦略に関する一般的な問題
  • team-CLI: コンソール UI
  • team-Configurability: 構成性チームにとっての問題。内容: コアビルド構成と移行システム。次を含まない: 新規または既存のフラグの変更 <ph type="x-smartling-placeholder">
  • team-Core: Skyframe、bazel クエリ、BEP、オプション解析、bazelrc
  • team-Documentation: ドキュメント チームの問題
  • team-ExternalDeps: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル
  • team-Loading-API: BUILD ファイルとマクロの処理（labels、package()、 visibility、glob）
  • team-Local-Exec: 実行（ローカル）チームに関する問題
  • team-OSS: Bazel OSS チームに関する問題: インストール、リリース プロセス、Bazel のパッケージング、ウェブサイト、ドキュメントのインフラストラクチャ
  • team-Performance: Bazel パフォーマンス チームの問題
  • team-Remote-Exec: 実行（リモート）チームの問題
  • team-Rules-API: ルール/アスペクトを書き込むための API: プロバイダ、実行ファイル、アクション、アーティファクト
  • team-Rules-CPP / team-Rules-ObjC: C++/Objective-C ルール（ネイティブ Apple ルールのロジックを含む）に関する問題
  • team-Rules-Java: Java ルールに関する問題
  • team-Rules-Python: Python のネイティブ ルールに関する問題
  • team-Rules-Server: Bazel に含まれるサーバーサイド ルールに関する問題
  • team-Starlark-Integration: 非 API Bazel と Starlark の統合。Bazel による Starlark インタープリタ、Stardoc、ビルトイン インジェクション、文字エンコードのトリガー方法について説明しています。ビルド言語や .bzl の言語に関する問題は含まれません。
  • team-Starlark-Interpreter: Starlark インタープリタの問題（java.net.starlark 内のすべて）。BUILD API と .bzl API の問題（Bazel と Starlark との統合）は team-Build-Language にあります。

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

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