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