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

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

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

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

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

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

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

  • リリース プロセス: Bazel のリリース プロセスを管理します。
  • グリーンチーム: ルールとツールの健全なエコシステムを成長させる。
  • デベロッパー エクスペリエンス ガーデナー: 外部からの貢献を促進し、問題とプルリクエストを確認して、開発ワークフローをよりオープンにします。

リリース

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

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

問題のライフサイクル

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

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

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

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

  1. ユーザーが pull リクエストを作成します。
  2. Bazel チームのメンバーで、自分の領域に関する PR を送信する場合は、チームラベルを割り当て、最適なレビュー担当者を見つける責任があります。
  3. それ以外の場合は、毎日のトリアージ中に、DevEx メンバーが 1 つのチームラベルと、ルーティング用のチームの技術リード(TL)を割り当てます。
    1. 必要に応じて、TL は PR の審査を他の人に割り当てることができます。
  4. 割り当てられたレビュー担当者は PR を確認し、承認または破棄されるまで作成者と連携します。
  5. 承認されると、審査担当者は PR のコミットを Google の さらにテストするために内部バージョン管理システムを使用します。Bazel は Google 内部で使用されているビルドシステムと同じであるため、すべての PR コミットを内部テストスイートでテストする必要があります。PR を直接統合しないのはそのためです。
  6. インポートされた commit がすべての内部テストに合格すると、commit は破棄されます GitHub に再度エクスポートします
  7. commit がマスターにマージされると、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
    • 現在、対応する時間や寄付を受け入れる時間がない問題。これらの問題は、誰も対応していないことを示すためにクローズされますが、時間の経過とともにその有効性を継続的にモニタリングし、十分な数のユーザーに影響があり、対応するリソースがある場合は復活させます。気軽にコメントやリアクションを追加しましょう。 閉じることもできます。

チームラベル

  • team-Android: Android チームの問題 <ph type="x-smartling-placeholder">
  • team-Bazel: Bazel プロダクト/戦略に関する一般的な問題 <ph type="x-smartling-placeholder">
  • team-CLI: コンソール UI <ph type="x-smartling-placeholder">
  • team-Configurability: 構成可能性チームの問題。内容: コアビルド構成と移行システム。次を含まない: 新規または既存のフラグの変更
  • team-Core: Skyframe、bazel クエリ、BEP、オプションの解析、bazelrc
  • team-Documentation: ドキュメント チームの問題 <ph type="x-smartling-placeholder">
  • team-ExternalDeps: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル <ph type="x-smartling-placeholder">
  • team-Loading-API: BUILD ファイルとマクロの処理(labels、package()、 visibility、glob) <ph type="x-smartling-placeholder">
  • team-Local-Exec: 実行(ローカル)チームに関する問題 <ph type="x-smartling-placeholder">
  • team-OSS: Bazel OSS チームの問題: インストール、リリース プロセス、Bazel パッケージング、ウェブサイト、ドキュメント インフラストラクチャ
  • team-Performance: Bazel パフォーマンス チームの問題 <ph type="x-smartling-placeholder">
  • team-Remote-Exec: 実行(リモート)チームの問題 <ph type="x-smartling-placeholder">
  • team-Rules-API: ルール / アスペクト(プロバイダ、ランファイル、アクション、アーティファクト)の記述用 API
  • team-Rules-CPP / team-Rules-ObjC: ネイティブ Apple ルール ロジックなど、C++ / Objective-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、ビルトイン インジェクション、文字エンコードのトリガー方法について説明しています。ビルド言語や .bzl の言語に関する問題は含まれません
  • team-Starlark-Interpreter: Starlark インタープリタの問題(java.net.starlark 内のすべて)。BUILD と .bzl API の問題(Bazel と Starlark の統合を表す)は team-Build-Language に分類します。

新しい問題については、チームラベルに置き換えるために category: * ラベルを非推奨にしました。

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