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

問題を報告 ソースを表示

これは、Bazel オープンソース プロジェクトの管理者を対象としたガイドです。

Bazel へのコントリビューションについては、Bazel へのコントリビューションをご覧ください。

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

  1. プロジェクトの貢献プロセスにおいて、メンテナンス担当者が信頼できる情報源の役割を果たす。
  2. コミュニティ貢献者とプロジェクト管理者の間で期待値を設定します。

Bazel のコア コントリビューター グループには、オープンソース プロジェクトのさまざまな側面を管理するための専用のサブチームがあります。わかっています。

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

リリース

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

bazelbuild/continuous-integration リポジトリで Bazel の CI インフラストラクチャに関する Green チームのガイドを確認する。

問題のライフサイクル

  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 メンバーは 1 つの platform: ラベルを割り当てます（Mac 固有の問題の場合は platform:apple）。
  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 がマスターにマージされると、GitHub は自動的に PR を閉じます。

チームはレーベルを所有しています。必要な対策

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

問題

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

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

pull リクエスト

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

優先度

管理者が問題を選別するために、次の優先度の定義を使用します。

  • P0 - Bazel リリース（リリース候補を除く）が使用できなくなる重大な機能不完全な機能、または Bazel プロジェクトの開発に重大な影響を及ぼすサービスの停止。これには、多数のユーザーをブロックする新しいリリースで導入された回帰や、互換性を破る変更ポリシーに準拠していない互換性のない互換性のない変更が含まれます。実用的な回避策がない。
  • P1 - 次のリリースで対処する必要がある重大な欠陥や機能、または多くのユーザー（Bazel プロジェクトの開発を含む）に影響を与える重大な問題があるが、実用的な回避策が存在する。通常、即時の対応は必要ありません。需要が多く、当四半期のロードマップで計画されています。
  • P2 - 対処する必要があるが、現在は対応していない欠陥または機能。リリースされた Bazel バージョンで発生しているライブ問題で、ユーザーにとっては不便であり、今後のリリースで対処する必要があるか、簡単な回避策が存在する。
  • P3 - 小さな影響で望ましい軽微なバグ修正または機能強化。Bazel ロードマップや緊急リリースでは優先されていませんが、コミュニティ貢献は推奨されます。
  • P4 - クローズされる可能性が低い、優先度の低い欠陥または機能リクエスト。より多くのユーザーが影響を受ける場合は、優先順位の変更に備えてオープン状態にしておくこともできます。
  • ice-box
    • 現時点では対処する時間がない問題や、コントリビューションを受け付ける時間がない問題。Google はこれらの問題に誰も対処していないことを示すためにこれらの問題を終了しますが、時間の経過とともにその妥当性を継続的にモニタリングし、十分な数の人々に影響が及び、対処するためのリソースが発生した場合は復活させます。これまでと同様に、これらの問題に対するコメントやリアクションの追加は、クローズ時でもご遠慮なくお願いいたします。

チームラベル

  • 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: ファイルとマクロのビルド処理: 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、組み込みインジェクション、文字エンコードなどです。BUILD または .bzl 言語に関する問題は含まれません。
  • team-Starlark-Interpreter: Starlark インタープリタの問題（java.net.starlark 内の任意のもの）。BUILD API と .bzl API の問題（Bazel と Starlark の統合に関する問題）は team-Build-Language に配置されます。

新しい問題では、category: * ラベルのサポートが終了し、チームラベルに置き換えられました。

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