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

問題を報告 ソースを表示

このガイドは、Bazel オープンソース プロジェクトのメンテナンス担当者を対象としています。

Bazel への貢献を検討している場合は、Bazel への貢献をご覧ください。

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

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

Bazel のコアコントリビューター グループには、オープンソース プロジェクトのさまざまな側面を管理する専門のサブチームがあります。具体的には、次のとおりです。

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

リリース

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

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

問題のライフサイクル

  1. ユーザーが問題テンプレートを使用して問題を作成し、未審査の未解決の問題のプールにランクインした。
  2. デベロッパー エクスペリエンス（DevEx）サブチーム ローテーションのメンバーが問題を確認します。
    1. 問題がバグでも機能リクエストでもない場合、DevEx メンバーは通常、問題をクローズし、質問をより明確に把握できるように StackOverflow と bazel-discuss にユーザーをリダイレクトします。
    2. 問題がコミュニティが所有するルール リポジトリ（rules_apple など）に属している場合、DevEx メンバーは適切なリポジトリにこの問題を転送します。
    3. 問題があいまいな場合や情報が不足している場合、DevEx メンバーは問題をユーザーに割り当て直し、続行する前に詳細情報を要求します。これは通常、お客様が Issue Template に従っていない場合に発生します。
  3. DevEx メンバーは問題を確認した後、その問題に緊急の対応が必要かどうかを判断します。その場合は、P0 優先度ラベルとチームリーダーのリストからオーナーを割り当てます。
  4. DevEx メンバーは、untriaged ラベルと 1 つのチームラベルのみをルーティング用に割り当てます。
  5. DevEx メンバーは、問題のタイプに応じて type: ラベル（type: bug や type: feature request など）を 1 つだけ割り当てます。
  6. プラットフォーム固有の問題の場合、DevEx メンバーは 1 つの platform: ラベルを割り当てます（Mac 固有の問題の場合は platform:apple など）。この段階で、問題は優先順位付けされていない未解決の問題のプールに入ります。

各 Bazel サブチームは、担当するラベルですべての問題を（できれば週 1 回）トリアージします。サブチームが問題を確認して評価し、可能であれば解決策を提供します。チームラベルのオーナーの方は、このセクション で詳細をご確認ください。

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

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 回）トリアージする必要があります。

問題

  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. 内部パッチを送信します。パッチの送信とエクスポートが正常に行われると、PR は GitHub によって自動的に終了します。

優先度

メンテナンス担当者は、優先度の以下の定義を使用して問題をトリアージします。

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

チームラベル

新しい問題では、category: * ラベルのサポートを終了し、チームラベルに置き換えました。

ラベルの完全なリストについては、こちらをご覧ください。