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

これは、Bazel オープンソース プロジェクトの管理者向けのガイドです。

Bazel に協力したい場合は、Bazel への投稿をご覧ください。

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

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

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

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

リリース

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

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

問題のライフサイクル

  1. ユーザーが Issue Template を使用して問題を作成すると、未審査の未解決の問題のプールに入ります。
  2. Developer Experience（DevEx）サブチームのローテーションのメンバーが問題を確認します。
    1. 問題がバグ以外や機能リクエストでない場合、DevEx のメンバーは通常、問題をクローズし、ユーザーを StackOverflow と bazel-discuss にリダイレクトして、質問をより明確にします。
    2. 問題がコミュニティが所有するルール リポジトリ（rules_apple など）に属している場合、DevEx メンバーは正しいリポジトリにこの問題を転送します。
    3. 問題があいまいであるか、情報が不足している場合、DevEx メンバーはユーザーに問題を割り当てて、次に進む前に追加情報をリクエストします。これは通常、ユーザーが問題テンプレートに従わない場合に発生します。
  3. DevEx のメンバーは問題を確認した後、問題に即時の対応が必要かどうかを判断します。合致する場合は、P0 優先度ラベルとチームリーダーのリストからオーナーを割り当てます。
  4. DevEx メンバーは、ルーティング用に untriaged ラベルと 1 つのチームラベルを割り当てます。
  5. DevEx メンバーは、問題の種類に応じて、type: bug や type: feature request などの type: ラベルを 1 つだけ割り当てます。
  6. プラットフォーム固有の問題の場合、DevEx メンバーは 1 つの platform: ラベルを割り当てます（Mac 固有の問題の場合は platform:apple など）。この段階で、問題はトリアージされていない未解決の問題のプールに入ります。

各 Bazel サブチームは、所有するラベルですべての問題を（できれば毎週）優先順位を付けます。サブチームが問題を確認して評価し、可能であれば解決策を提供します。チームラベルのオーナーの場合は、このセクション で詳細をご確認ください。

問題が解決したらクローズできます。

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. pull リクエスト作成者と協力してコードレビューを完了します。
  4. PR を承認します。
  5. すべてのテストに合格することを確認します。
  6. パッチを内部バージョン管理システムにインポートし、内部の presubmit を実行します。
  7. 内部パッチを送信します。パッチが正常に送信されてエクスポートされると、GitHub によって PR が自動的に閉じられます。

優先度

管理者が問題をトリアージする際に使用する優先度は次のとおりです。

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

チームラベル

新しい問題については、category: * ラベルを非推奨とし、チームラベルに置き換えました。

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