これは、Bazel オープンソース プロジェクトのメンテナー向けのガイドです。
Bazel への貢献をお考えの場合は、Contributing to Bazel をご覧ください。
このページの目的は次のとおりです。
- プロジェクトのコントリビューション プロセスのメンテナーの信頼できる情報源として機能する。
- コミュニティのコントリビューターとプロジェクトのメンテナーの間で期待値を設定する。
Bazel の コア コントリビューター グループには、オープンソース プロジェクトのさまざまな側面を管理するための専用の サブチームがあります。それらは以下のとおりです。
- リリース プロセス: Bazel のリリース プロセスを管理します。
- Green Team: Bazel CI の健全性をモニタリングし、破損を報告します。
- Developer Experience Gardeners: 外部からのコントリビューションを促進し、 問題と pull リクエストを確認して、開発ワークフローをよりオープンにします。
リリース
継続的インテグレーション
bazelbuild/continuous-integration リポジトリで、Green チームの Bazel CI インフラストラクチャに関するガイドをご覧ください。
問題のライフサイクル
- ユーザーが 問題テンプレートのいずれかを選択して問題を作成すると、 未審査のオープンな 問題のプールに追加されます。
- Developer Experience（DevEx）サブチームのローテーションのメンバーが問題を確認します。
- 問題がバグや機能リクエストでない場合、通常、DevEx メンバーは問題をクローズし、質問の可視性を高めるためにユーザーを StackOverflowと bazel-discussにリダイレクトします。
- rules_apple
- 問題が曖昧な場合や情報が不足している場合、DevEx メンバーは問題をユーザーに割り当てて、続行する前に詳細情報をリクエストします。これは通常、ユーザーが適切な 問題テンプレート {: .external} を選択していない場合や、情報が不完全な場合に発生します。
- 問題を確認した後、DevEx メンバーは問題に早急な対応が必要かどうかを判断します。必要な場合は、P0 優先度ラベルと、チームリーダーのリストからオーナーを割り当てます。
- DevEx メンバーは、ルーティング用に
untriagedラベルと 1 つの チーム ラベルを割り当てます。 - また、DevEx メンバーは、問題のタイプに応じて、
type: bugやtype: feature requestなどのtype:ラベルを 1 つだけ割り当てます。 - プラットフォーム固有の問題の場合、DevEx メンバーは、Mac 固有の問題の場合は
platform:appleなど、platform:ラベルを 1 つ割り当てます。 - 問題の優先度が低く、新しいコミュニティ コントリビューターが対応できる場合は、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 が master にマージされると、GitHub は PR を自動的にクローズします。
私のチームがラベルを所有しています。どうすればよいですか？
サブチームは、所有するラベルのすべての問題をトリアージする必要があります。 できれば週に 1 回行うことをおすすめします。
問題
- チームラベルと
untriagedラベルで問題のリストをフィルタします。 - 問題を確認します。
- 優先度を特定してラベルを割り当てます。
- 問題が P0 の場合、DevEx サブチームによって優先順位が付けられている可能性があります。必要に応じて優先順位を付け直してください。
- 各問題には、優先度ラベルが 1 つだけ必要です。問題が P0 または P1 の場合は、対応中であると想定されます。
untriagedラベルを削除します。
ラベルを追加または削除するには、bazelbuild organization に所属している必要があります。
pull リクエスト
pull リクエスト（PR）は、外部のコントリビューターが Bazel に価値を追加する主な方法です。オープンソース プロジェクトとして、PR がタイムリーかつ効率的にレビューされ、処理されるようにすることが重要です。
優先順位付け
awaiting-reviewラベルとチームラベルが付いた受信 PR を定期的に確認します。これは、ローテーションまたは定期的なトリアージ ミーティングで行うことができます。 各 PR には、7 営業日以内に最初のレスポンスが届く予定です。レスポンス
- PR に問題がない場合は、承認して
awaiting-PR-mergeラベルを適用します。gTech チームが PR を CL としてインポートします。 - それ以外の場合は、フィードバックを残して、
awaiting-reviewラベルをawaiting-user-responseラベルに置き換えます。PR の作成者が返信した場合、DevEx サブチームはラベルを定期的に更新します。 - 大幅な変更を含む PR の場合は、設計ドキュメントまたは問題での事前ディスカッションをリクエストすることを検討してください。
- PR に問題がない場合は、承認して
クローズ
リソースが限られているため、Bazel の標準を満たしていない PR や、レビューまたはメンテナンスを行うことができない PR はクローズすることが重要です。
- PR が Bazel の目標に沿っていない場合は、説明を添えてクローズします。
- PR が大きすぎて複雑な場合は、小さな単位に分割するようリクエストしてクローズします。
- PR のコード品質が Google の基準を満たしていない場合は、説明を添えてクローズします。
- コードの今後のメンテナンス費用が高すぎる場合は、説明を添えてクローズします。
- PR がユーザーのレスポンスを長時間待っていて、コントリビューターが返信していない場合、PR は 30 日後に自動的に古いものとしてマークされ、さらに 30 日後にクローズされます。
PR をクローズするときは、丁寧に対応し、クローズの理由を説明してください。
優先度
メンテナーは、次の優先度の定義を使用して問題をトリアージします。
- P0 - Bazel リリース（リリース候補を除く）が使用できなくなる重大な機能の破損、または Bazel プロジェクトの開発に深刻な影響を与えるサービス停止。これには、多数のユーザーをブロックする新しいリリースで導入された回帰や、 破壊的変更ポリシーに準拠していない互換性のない破壊的変更が含まれます。実用的な回避策はありません。
- P1 - 次のリリースで対応する必要がある重大な欠陥または 機能、または多くのユーザー（Bazel プロジェクトの開発を含む）に影響を与える重大な問題ですが、 実用的な回避策があります。通常、早急な対応は必要ありません。需要が高く、今四半期のロードマップで計画されています。
- P2 - 対応する必要がある欠陥または機能 ですが、現在対応していません。リリースされた Bazel バージョンで、ユーザーにとって不便な中程度のライブ問題。今後のリリースで対応する必要があるか、簡単な回避策が存在します。
- P3 - 影響の小さい望ましい軽微なバグ 修正または機能強化。Bazel のロードマップや今後のリリースでは優先されませんが、コミュニティからのコントリビューションは歓迎します。
- P4 - 優先度の低い欠陥 またはクローズされる可能性の低い機能リクエスト。より多くのユーザーに影響する場合は、優先順位を再設定するためにオープンにしておくこともできます。
チームラベル
team-Android: Android チームの問題- 連絡先: ahumesky
team-Bazel: Bazel プロダクト/戦略に関する一般的な問題- 連絡先: meisterT
team-CLI: コンソール UI- 連絡先: meisterT
team-Configurability: 構成可能性チームの問題。含まれるもの: コアビルド構成と移行システム。含まれないもの: 新しいフラグまたは既存のフラグの変更- 連絡先: gregestren
team-Core: Skyframe、bazel query、BEP、オプションの解析、bazelrc- 連絡先: haxorz
team-Documentation: ドキュメント チームの問題team-ExternalDeps: 外部依存関係の処理、Bzlmod、リモート リポジトリ、WORKSPACE ファイル- 連絡先: meteorcloudy
team-Loading-API: BUILD ファイルとマクロ処理: ラベル、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: プロバイダ、runfiles、アクション、アーティファクト- 連絡先: pzembrod
team-Rules-CPP/team-Rules-ObjC: ネイティブ Apple ルールロジックを含む C++/Objective-C ルールの問題- 連絡先: pzembrod
team-Rules-Java: Java ルールの問題- 連絡先: hvadehra
team-Rules-Python: ネイティブ Python ルールの問題- 連絡先: rickeylev
team-Rules-Server: Bazel に含まれるサーバーサイド ルールの問題- 連絡先: pzembrod
team-Starlark-Integration: API 以外の Bazel + Starlark 統合。含まれるもの: Bazel が Starlark インタープリタをトリガーする方法、Stardoc、組み込みの挿入、文字エンコード。 含まれないもの: BUILD 言語または .bzl 言語の問題。- 連絡先: brandjon
team-Starlark-Interpreter: Starlark インタープリタの問題（java.net.starlark のすべて）。BUILD API と .bzl API の問題（Bazel と Starlark の統合を表す）はteam-Build-Languageにあります。- 連絡先: brandjon
新しい問題については、チームラベルを優先して category: * ラベルは非推奨になりました。
ラベルの完全なリストはこちらをご覧ください。