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

Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.7

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

Bazel への貢献をご希望の場合は、Bazel への貢献をご覧ください。

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

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

Bazel のコア貢献者グループには、オープンソース プロジェクトのさまざまな側面を管理する専用のサブチームがあります。それらは以下のとおりです。

  • リリース プロセス: Bazel のリリース プロセスを管理します。
  • Green Team: ルールとツールの健全なエコシステムを構築します。
  • Developer Experience Gardeners: 外部からの貢献を促し、問題とプルリクエストを確認し、開発ワークフローをよりオープンにします。

リリース

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

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

問題のライフサイクル

  1. ユーザーが問題テンプレートのいずれかを選択して問題を作成すると、その問題は未確認の未解決の問題のプールに入ります。
  2. デベロッパー エクスペリエンス（DevEx）サブチームのローテーション担当者が問題を審査します。
    1. 問題がバグや機能リクエストでない場合、通常、DevEx メンバーは問題をクローズし、質問の可視性を高めるために、ユーザーを StackOverflow と bazel-discuss にリダイレクトします。
    2. 問題が rules_apple などのコミュニティが所有するルール リポジトリのいずれかに該当する場合は、DevEx メンバーがこの問題を適切なリポジトリに転送します。
    3. 問題が曖昧な場合や情報が不足している場合は、DevEx メンバーは問題をユーザーに割り当て直し、続行する前に詳細な情報をリクエストします。通常、これはユーザーが適切な問題テンプレート{: .external}を選択していない場合や、提供された情報が不完全な場合に発生します。
  3. DevEx メンバーは、問題を審査した後、問題に早急な対応が必要かどうかを判断します。その場合は、P0 priority ラベルと、チームリーダーのリストからオーナーを割り当てます。
  4. DevEx メンバーは、ルーティング用に untriaged ラベルと 1 つのチームラベルを割り当てます。
  5. また、DevEx メンバーは、問題のタイプに応じて type: bug や type: feature request などの type: ラベルを 1 つだけ割り当てます。
  6. プラットフォーム固有の問題については、DevEx メンバーが 1 つの platform: ラベル（Mac 固有の問題の場合は platform:apple など）を割り当てます。
  7. 問題の優先度が低く、新しいコミュニティ投稿者が対応できる場合は、DevEx メンバーが good first issue ラベルを割り当てます。この段階で、問題は未トリアージの未解決の問題のプールに入ります。

各 Bazel サブチームは、所有するラベルのすべての問題をトリアージします。できれば毎週行うことが望ましいです。サブチームが問題を審査して評価し、可能であれば解決策を提供します。チームラベルのオーナーの場合は、こちらのセクション をご覧ください。

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

pull リクエストのライフサイクル

  1. ユーザーが pull リクエストを作成します。
  2. Bazel チームのメンバーで、自分のエリアに対して PR を送信する場合は、チームラベルを割り当てて最適なレビュー担当者を見つける必要があります。
  3. それ以外の場合は、毎日のトリアージで、DevEx メンバーがルーティング用のチームラベルとチームのテクニカル リード（TL）を割り当てます。
    1. TL は、PR の審査を他のユーザーに割り当てることができます。
  4. 割り当てられたレビュー担当者は PR をレビューし、承認または破棄されるまで作成者と協力します。
  5. 承認されると、審査担当者は PR のコミットを Google の内部バージョン管理システムにインポートして、さらなるテストを行います。Bazel は Google の内部で使用されているのと同じビルドシステムであるため、すべての PR コミットを内部テストスイートに対してテストする必要があります。これが、PR を直接マージしない理由です。
  6. インポートされたコミットがすべての内部テストに合格すると、コミットはスクワッシュされ、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. パッチを内部バージョン管理システムにインポートし、内部 presubmit を実行します。
  7. 内部パッチを送信します。パッチの送信とエクスポートが正常に完了すると、GitHub によって PR が自動的に閉じられます。

優先度

優先度の定義は、メンテナーが問題をトリアージするために使用します。

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

チームラベル

新しい問題については、チームラベルを優先して category: * ラベルを非推奨にしました。

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