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

<ph type="x-smartling-placeholder"></ph> 問題を報告する ソースを表示 夜間 · 7.3 · 7.2 · 7.1 · 7.0 · 6.5

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

Bazel へのコントリビューションについては、Google Cloud プロダクトへの貢献 Bazel を使用してください。

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

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

Bazel のコアコントリビューター グループには、 さまざまな役割を担います。具体的には、次のとおりです。

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

リリース

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

Green チームの Bazel の CI インフラストラクチャガイドを読む bazelbuild/continuous-integration できます。

問題のライフサイクル

  1. ユーザーが [Issue（問題）] テンプレート 未審査の営業待ちのプールに入り をご覧ください。
  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: ラベルも 1 つだけ割り当てます。 または type: feature request（問題のタイプに応じて異なります）。
  6. プラットフォーム固有の問題の場合、DevEx メンバーは 1 つの platform: ラベルを割り当てます。 たとえば、Mac 固有の問題の場合は platform:apple です。 この段階で、問題は未優先順位付けの をご覧ください。

各 Bazel サブチームは、所有するラベルに基づいてすべての問題をトリアージします。トリアージは、可能であれば できます。サブチームが問題を確認、評価して、 推奨されます。チームラベルのオーナーの方は、こちらのセクション をご覧ください。

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

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

  1. ユーザーが pull リクエストを作成します。
  2. Bazel チームのメンバーで、自分の地域に対して PR を送信する場合は、 チームにラベルを割り当てて、最適な 確認しましょう。
  3. それ以外の場合は、毎日のトリアージ時に、DevEx メンバーが チームラベルと、ルーティングを担当するチームのテクニカル リード（TL）を記録します。
    1. TL は必要に応じて、PR を確認する別の担当者を割り当てることもできます。
  4. 割り当てられたレビュアーが PR を確認し、問題がなければ執筆者と協力します。 拒否されます。
  5. 承認されると、審査担当者は PR のコミットを Google の 内部バージョン管理システムを使用して さらにテストできるようにしましたBazel は同じビルドであるため、 すべての PR コミットを 内部テストスイートを使用しますPR を直接統合しないのはそのためです。
  6. インポートされた commit がすべての内部テストに合格すると、commit は破棄されます GitHub に再度エクスポートします
  7. commit がマスターにマージされると、GitHub は自動的に PR を閉じます。

私のチームはラベルを持っています。必要な対策

サブチームは、担当するラベルのすべての問題を分類する必要があります。 できれば毎週。

問題

  1. 問題のリストをチームラベルと untriaged ラベルでフィルタします。
  2. 問題を確認します。
  3. 優先度を特定してラベルを割り当てます。
    1. DevEx サブチームによってこの問題の優先順位付けがすでになされている可能性があります。 P0.必要に応じて優先順位を変更します。
    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
    • 現在対処する時間がない問題や 寄付を受け付けるまでの時間が長くなります。Google はこれらの問題をクローズし、 作業している人はいませんが 十分な数の人が影響を受けた場合や リソースが必要になります気軽にコメントやリアクションを追加しましょう。 閉じることもできます。

チームラベル

新しい問題では、チームに代わって category: * ラベルのサポートを終了しました。 できます。

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