このガイドは、Bazel オープンソース プロジェクトの管理者を対象としています。
Bazel に協力する場合は、Bazel への貢献をご覧ください。
このページの目的は次のとおりです。
- プロジェクトのコントリビューション プロセスでメンテナの信頼できる情報源として機能します。
- コミュニティ協力者とプロジェクト管理者の間に期待を設定します。
Bazel のコントリビューターのコアグループは、オープンソース プロジェクトの側面を管理する専任のサブチームを持っています。わかっています。
- リリース プロセス: Bazel のリリース プロセスを管理します。
- グリーンチーム: ルールとツールの健全なエコシステムを成長させます。
- デベロッパー エクスペリエンス ガーデナー: 外部への協力、問題の確認、pull リクエストを行い、開発ワークフローをよりオープンにします。
リリース
継続的インテグレーション
bazelbuild/continuous-integration リポジトリで Bazel の CI インフラストラクチャに関する Green チームガイドをお読みください。
問題のライフサイクル
- ユーザーが問題テンプレートを使用して問題を作成すると、それが未確認の未解決の問題のプールに入ります。
- デベロッパー エクスペリエンス（DevEx）のサブチーム ローテーションのメンバーがこの問題を審査しました。
- 問題がバグでも機能リクエストでもない場合、DevEx メンバーは通常、問題をクローズして StackOverflow と bazel-discuss にユーザーをリダイレクトします。これにより、質問の可視性が高まります。
- 問題が、コミュニティが所有するルール リポジトリ（rules_apple など）に属している場合、DevEx のメンバーはこの問題を正しいリポジトリに転送します。
- 問題が不明瞭な場合、または情報が不足している場合、DevEx のメンバーは問題をユーザーに再割り当てしてから、続行する前に追加情報をリクエストします。これは通常、ユーザーが問題テンプレートの手順を実行していない場合に発生します。
- 問題を確認した後、DevEx メンバーは、問題に対して早急な対応が必要かどうかを判断します。存在する場合は、P0 の優先度ラベルと、チームリードのリストからオーナーを割り当てます。
- DevEx メンバーは、ルーティング用に
untriagedラベルと 1 つのチームラベルを割り当てます。 - DevEx メンバーは、問題の種類に応じて
type:（type: bugやtype: feature requestなど）のラベルを 1 つだけ割り当てます。 - プラットフォーム固有の問題の場合、DevEx メンバーは
platform:ラベルを 1 つ（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 コミットをすべて内部テストスイートに対してテストする必要があります。Google が PR を直接統合することはありません。
- インポートされた commit がすべての内部テストに合格すると、commit は圧縮されて GitHub にエクスポートされます。
- commit がマスターにマージされると、GitHub は自動的に PR を終了します。
自分のチームがラベルを持っているのに、必要な対策
サブチームは、所有するラベルの問題を、できれば毎週確認する必要があります。
問題
- チームラベルと
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: スカイフレーム、bazel クエリ、BEP、オプション解析、bazelrc- 連絡先: haxorz
team-Documentation: ドキュメント チームの問題- 連絡先: philomathing
team-ExternalDeps: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル- 連絡先: meteorcloudy
team-Loading-API: BUILD ファイルとマクロ処理: labels、package()、visible、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: 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、組み込みインジェクション、文字エンコードをトリガーする方法BUILD 言語または .bzl 言語の問題は含まれません。- 連絡先: brandjon
team-Starlark-Interpreter: Starlark インタープリタに関する問題（java.net.starlark のすべて）。BUILD と .bzl API の問題（Bazel と Starlark の統合）はteam-Build-Languageにあります。- 連絡先: brandjon
新しい問題では、category: * ラベルを非推奨とし、チームラベルに置き換えました。
ラベルの一覧については、こちらをご覧ください。