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

問題を報告する ソースを表示 Nightly · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

これは、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 メンバーは問題をユーザーに割り当て直し、続行する前に詳細な情報をリクエストします。これは通常、ユーザーが問題テンプレートに沿っていない場合に発生します。
  3. DevEx メンバーは、問題を審査した後、問題に早急な対応が必要かどうかを判断します。その場合は、P0 priority ラベルと、チームリーダーのリストからオーナーを割り当てます。
  4. DevEx メンバーは、ルーティング用に untriaged ラベルと 1 つのチームラベルを割り当てます。
  5. また、DevEx メンバーは、問題のタイプに応じて type: bug や type: feature request などの type: ラベルを 1 つだけ割り当てます。
  6. プラットフォーム固有の問題については、DevEx メンバーが 1 つの platform: ラベル（Mac 固有の問題の場合は platform:apple など）を割り当てます。この段階で、問題は未トリアージの未解決の問題のプールに入ります。

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

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

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

  1. ユーザーが pull リクエストを作成します。
  2. Bazel チームのメンバーで、自分のエリアに対して PR を送信する場合は、チームラベルを割り当てて最適なレビュー担当者を見つける必要があります。
  3. それ以外の場合は、毎日のトリアージで、DevEx メンバーが 1 つのチームラベルと、ルーティング用のチームのテクニカル リード（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: * ラベルを非推奨にしました。

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