このガイドは、Bazel オープンソース プロジェクトのメンテナンス担当者を対象としています。
Bazel への貢献を検討している場合は、Bazel への貢献をご覧ください。
このページの目標は次のとおりです。
- プロジェクトのコントリビューション プロセスにおいて、メンテナンス担当者の信頼できる情報源として機能します。
- コミュニティのコントリビューターとプロジェクト メンテナンス担当者の間で期待値を設定します。
Bazel のコアコントリビューター グループには、オープンソース プロジェクトのさまざまな側面を管理する専門のサブチームがあります。具体的には、次のとおりです。
- リリース プロセス: Bazel のリリース プロセスを管理します。
- グリーンチーム: ルールとツールの健全なエコシステムを成長させる。
- デベロッパー エクスペリエンス ガーデナー: 外部貢献を奨励し、問題と pull リクエストをレビューして、開発ワークフローをよりオープンなものにします。
リリース
継続的インテグレーション
bazelbuild/continuous-integration リポジトリで Green チームの Bazel の CI インフラストラクチャに関するガイドを読む。
問題のライフサイクル
- ユーザーがいずれかの問題テンプレートを選択して問題を作成すると、未審査の未解決の問題のプールに入ります。
- デベロッパー エクスペリエンス(DevEx)サブチーム ローテーションのメンバーが問題を確認します。
- 問題がバグでも機能リクエストでもない場合、DevEx メンバーは通常、問題をクローズし、質問をより明確に把握できるように StackOverflow と bazel-discuss にユーザーをリダイレクトします。
- 問題がコミュニティが所有するルール リポジトリ(rules_apple など)に属している場合、DevEx メンバーは適切なリポジトリにこの問題を転送します。
- 問題があいまいな場合や情報が不足している場合、DevEx メンバーは問題をユーザーに割り当て直し、続行する前に詳細情報を要求します。これは通常、ユーザーが適切な問題テンプレート {: .external} を選択していないか、提供された情報が不完全である場合に発生します。
- DevEx メンバーは問題を確認した後、その問題に緊急の対応が必要かどうかを判断します。その場合は、P0 優先度ラベルとチームリーダーのリストからオーナーを割り当てます。
- DevEx メンバーは、
untriaged
ラベルと 1 つのチームラベルのみをルーティング用に割り当てます。 - DevEx メンバーは、問題のタイプに応じて
type:
ラベル(type: bug
やtype: feature request
など)を 1 つだけ割り当てます。 - プラットフォーム固有の問題の場合、DevEx メンバーは 1 つの
platform:
ラベルを割り当てます(Mac 固有の問題の場合はplatform:apple
など)。 - 問題の優先度が低く、新しいコミュニティ貢献者が対応できる場合、DevEx メンバーは
good first issue
ラベルを割り当てます。この段階で、問題は優先順位付けされていない未解決の問題のプールに入ります。
各 Bazel サブチームは、担当するラベルですべての問題を(できれば週 1 回)トリアージします。サブチームが問題を確認して評価し、可能であれば解決策を提供します。チームラベルのオーナーの方は、このセクション で詳細をご確認ください。
問題が解決したらクローズできます。
pull リクエストのライフサイクル
- ユーザーが pull リクエストを作成します。
- Bazel チームのメンバーで、自分の地域に対して PR を送信する場合は、チームにラベルを割り当て、最適なレビュー担当者を見つける責任があります。
- それ以外の場合は、毎日のトリアージ時に、DevEx メンバーが 1 つのチームラベルとチームのテクニカル リード(TL)をルーティングに割り当てます。
- TL は必要に応じて、PR を確認する別の担当者を割り当てることもできます。
- 割り当てられたレビュー担当者は PR を確認し、承認または削除されるまで作成者と連携します。
- 承認されると、審査担当者は PR の commit を Google の内部バージョン管理システムにインポートして、さらにテストを実施します。Bazel は Google 内部で使用されているビルドシステムと同じであるため、内部テストスイートに対してすべての PR commit をテストする必要があります。PR を直接統合しないのはそのためです。
- インポートされた commit がすべての内部テストに合格すると、その commit は破棄され、GitHub にエクスポートされます。
- commit がマスターにマージされると、GitHub は自動的に PR を閉じます。
私のチームはラベルを持っています。必要な対策
サブチームは、所有するラベルのすべての問題を(できれば週 1 回)トリアージする必要があります。
問題
- 問題のリストをチームラベルと
untriaged
ラベルでフィルタします。 - 問題を確認します。
- 優先度を特定してラベルを割り当てます。
- 問題が P0 の場合、DevEx サブチームによってすでに優先順位付けされている可能性があります。必要に応じて優先順位を変更します。
- 各問題には 1 つの優先度ラベルが必要です。問題が P0 または P1 の場合、現在対応中であると見なされます。
untriaged
ラベルを削除します。
ラベルを追加または削除するには、bazelbuild 組織に属している必要があります。
pull リクエスト
- pull リクエストのリストをチームラベルでフィルタする。
- 未解決の pull リクエストを確認します。
- 省略可: レビューを担当しているがレビューに適していない場合は、適切なレビュー担当者を再割り当てしてコードレビューを実施します。
- pull リクエストの作成者と協力してコードレビューを実施します。
- PR を承認します。
- すべてのテストに合格することを確認します。
- パッチを内部バージョン管理システムにインポートし、内部 presubmit を実行します。
- 内部パッチを送信します。パッチの送信とエクスポートが正常に行われると、PR は GitHub によって自動的に終了します。
優先度
メンテナンス担当者は、優先度の以下の定義を使用して問題をトリアージします。
- P0 - 重大な機能不備で、Bazel リリース(リリース候補を除く)が使用不能になったり、サービスの停止によって Bazel プロジェクトの開発に重大な影響が及んだりします。これには、多数のユーザーをブロックする新しいリリースで導入された回帰や、互換性を破る変更ポリシーに準拠していない互換性のない互換性を破る変更が含まれます。実用的な回避策は存在しない。
- P1 - 次のリリースで対処すべき重大な欠陥または機能。または、多くのユーザーに影響を与える重大な問題(Bazel プロジェクトの開発を含む)ですが、実用的な回避策があります。通常、すぐに対応する必要はありません。需要が高く、当四半期のロードマップで計画中。
- P2 - 対処する必要があるものの、現在対応していない欠陥または機能。リリースされた Bazel バージョンで発生し、今後のリリースで対処する必要がある、または簡単な回避策が存在するユーザーにとって不便な、中程度のライブの問題。
- P3 - 軽微なバグ修正または機能強化で、影響が小さいものです。Bazel ロードマップや目前のリリースでは優先されていませんが、コミュニティへの貢献が推奨されています。
- P4 - 優先度が低い問題、またはクローズされる可能性が低い機能リクエスト。また、影響を受けるユーザーが増えた場合に備えて、優先順位を変更するためにオープンのままにすることもできます。
- アイスボックス
- 現在対処する時間がない、寄付を承認する時間も設けられていない問題。これらの問題はクローズされ、誰も取り組んでいないことを示します。ただし、引き続き有効性をモニタリングし、十分な人数の影響を受けている場合や、問題に対処するためのリソースがある場合には、問題を復元します。クローズされた問題に対しても、いつでもコメントやリアクションをお寄せください。
チームラベル
team-Android
: Android チームの問題- 連絡先: ahumesky
team-Bazel
: Bazel プロダクト/戦略に関する一般的な問題- 連絡先: sventiffe
team-CLI
: コンソール UI- 連絡先: meisterT
team-Configurability
: 構成性チームにとっての問題。内容: コアビルド構成と移行システム。含まれないもの: 新規または既存のフラグの変更- 連絡先: gregestren
team-Core
: Skyframe、bazel クエリ、BEP、オプション解析、bazelrc- 連絡先: haxorz
team-Documentation
: ドキュメント チームの問題- 連絡先: philomathing
team-ExternalDeps
: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル- 連絡先: meteorcloudy
team-Loading-API
: BUILD ファイルとマクロの処理(labels、package()、 visibility、glob)- 連絡先: brandjon
team-Local-Exec
: 実行(ローカル)チームに関する問題- 連絡先: meisterT
team-OSS
: Bazel OSS チームに関する問題: インストール、リリース プロセス、Bazel のパッケージング、ウェブサイト、ドキュメントのインフラストラクチャ- 連絡先: meteorcloudy
team-Performance
: Bazel パフォーマンス チームの問題- 連絡先: meisterT
team-Remote-Exec
: 実行(リモート)チームにとっての問題- 連絡先: coeuvre
team-Rules-API
: ルール/アスペクトを書き込むための API(プロバイダ、実行ファイル、アクション、アーティファクト)- 連絡先: comius
team-Rules-CPP
/team-Rules-ObjC
: C++/Objective-C ルール(ネイティブ Apple ルールのロジックを含む)に関する問題- 連絡先: oquenchil
team-Rules-Java
: Java ルールの問題- 連絡先: hvadehra
team-Rules-Python
: ネイティブ Python ルールの問題- 連絡先: rickeylev
team-Rules-Server
: Bazel に含まれるサーバー側のルールに関する問題- 連絡先: comius
team-Starlark-Integration
: 非 API Bazel と Starlark の統合。Bazel による Starlark インタープリタ、Stardoc、ビルトイン インジェクション、文字エンコードのトリガー方法について説明しています。ビルド言語や .bzl の言語に関する問題は含まれません。- 連絡先: brandjon
team-Starlark-Interpreter
: Starlark インタープリタの問題(java.net.starlark 内のすべて)。BUILD API と .bzl API の問題(Bazel と Starlark との統合)はteam-Build-Language
にあります。- 連絡先: brandjon
新しい問題では、category: *
ラベルのサポートを終了し、チームラベルに置き換えました。
ラベルの完全なリストについては、こちらをご覧ください。