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

問題を報告する ソースを表示 ナイトリー · 8.0 7.4 . 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

Bazel に貢献する場合は、代わりに Bazel への貢献をご覧ください。

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

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

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

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

リリース

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

bazelbuild/continuous-integration リポジトリで、Green チームの Bazel の CI インフラストラクチャに関するガイドをご覧ください。

問題のライフサイクル

  1. ユーザーが問題テンプレートを使用して問題を作成すると、未確認のオープンな問題のプールに追加されます。
  2. デベロッパー エクスペリエンス（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 の内部バージョン管理システムにimportsして、さらにテストします。Bazel は Google 内部で使用されているビルドシステムと同じであるため、すべての PR コミットを内部テストスイートでテストする必要があります。そのため、PR を直接マージしないでください。
  6. インポートされた commit がすべての内部テストに合格すると、commit はス quash され、GitHub にエクスポートされます。
  7. commit が master にマージされると、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. パッチを内部バージョン管理システムにインポートし、内部の事前送信を実行します。
  7. 内部パッチを送信します。パッチが正常に送信され、エクスポートされると、PR は GitHub によって自動的にクローズされます。

優先度

メンテナンス担当者は、次の優先度の定義を使用して問題の優先度を判断します。

  • P0 - Bazel リリース（リリース候補版を除く）が使用できなくなる、または Bazel プロジェクトの開発に重大な影響を与えるサービスが停止する、重大な機能の破損。これには、多数のユーザーをブロックする新しいリリースで導入されたリグレッションや、互換性のない破壊的変更ポリシーに準拠していない互換性のない破壊的変更が含まれます。実用的な回避策はありません。
  • P1 - 次のリリースで対処する必要がある重大な欠陥または機能、または多くのユーザーに影響する重大な問題（Bazel プロジェクトの開発を含む）だが、実用的な回避策が存在する。通常、直ちに対応する必要はありません。需要が高く、今四半期のロードマップに予定されている。
  • P2 - 対処が必要な欠陥または機能だが、現在は対応していない。リリース済みの Bazel バージョンの重大なライブの問題。ユーザーにとって不便であり、今後のリリースで対処する必要がある、または簡単な回避策が存在する。
  • P3 - 影響が小さいマイナーなバグの修正や機能強化が望ましい。Bazel のロードマップや差し迫ったリリースでは優先度が低いですが、コミュニティからの貢献は歓迎されます。
  • P4 - 優先度の低いデバッグや、クローズされる可能性の低い機能リクエスト。より多くのユーザーに影響が及ぶ可能性がある場合は、優先度を再調整するためにオープンのままにすることもできます。
  • ice-box
    • 現在、対応する時間や寄付を受け入れる時間がない問題。これらの問題は、誰も対応していないことを示すためにクローズされますが、問題の有効性は引き続きモニタリングされ、十分な数のユーザーに影響が及んでおり、対応できるリソースがある場合は復活します。いつものように、クローズされた問題についても、コメントやリアクションを追加してください。

チームラベル

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

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