コンパイラーチームについて
注記: チームについての詳細は Forge 上 に多く存在しており、以下の大半は古くなっています。
rustc は Rust コンパイラーチームによって保守されています。 このチームに所属する人々は、共同でリグレッションの追跡や新機能の実装に取り組んでいます。 Rust コンパイラーチームのメンバーは、rustc とその設計に対して重要な貢献を行ってきた人々です。
議論
現在、コンパイラーチームは Zulip でチャットしています。
- チームチャットは Zulip インスタンス上の
t-compilerストリームで行われます - 関連する Zulip チャンネルも他にいくつかあります。
たとえば
t-compiler/helpでは rustc 開発について助けを求めることができ、t-compiler/meetingsではチームが週次のトリアージミーティングと運営ミーティングを行っています。
レビュアー
コンパイラーの特定の部分について誰が質問に答えられるのかを知りたい場合や、単に誰が何に取り組んでいるのかを知りたい場合は、 triagebot.toml の assign セクションを確認してください。 そこには、コンパイラーのさまざまな部分と、それぞれの部分のレビュアーである人々の一覧が含まれています。
Rust コンパイラーミーティング
コンパイラーチームには週次ミーティングがあり、そこでトリアージを行い、 一般に新しいバグやリグレッションを把握し、重要な事柄全般について議論するよう努めています。 ミーティングは Zulip で開催されます。 おおよそ次のように進行します。
- お知らせ、MCP/FCP、WG チェックイン: チームの残りのメンバーに対して、 全員に知っておいてほしい重要な事柄についていくつかのお知らせを共有します。 また、MCP と FCP の状況も共有し、 いくつかの WG から作業状況の更新を聞く機会としても使います。
- beta および stable へのノミネーションの確認: これらは、それぞれ beta と stable に バックポートするもののノミネーションです。 その後、実際に使われている、以前は動作していたコードをコンパイラーが壊した新しいケースを探します。 リグレッションは修正すべき重要な問題であるため、 P-critical または P-high としてタグ付けされている可能性があります。主な例外は バグ修正です（ただしその場合でも、私たちは多くの場合 まず警告を出すことを目指します）。
- P-critical および P-high のバグのレビュー: P-critical および P-high のバグは、 私たちが進捗を能動的に追跡するのに十分重要なものです。 P-critical および P-high のバグには、理想的には常に担当者がいるべきです。
S-waiting-on-t-compilerおよびI-compiler-nominatedissue の確認: これらは、 チームからのフィードバックが求められている issue です。- パフォーマンストリアージレポートの確認: パフォーマンスを悪化させた PR を確認し、 パフォーマンスリグレッションを revert する価値があるのか、それとも そのリグレッションを将来の PR で対処できるのかを判断しようとします。
現在、ミーティングは木曜日のボストン時間午前 10 時に行われています （通常は UTC-4 ですが、サマータイムによって複雑になることがあります）。
チームメンバーシップ
Rust チームのメンバーシップは通常、ある人がしばらくの間 コンパイラーに対して重要な貢献を行ってきたときに提供されます。 メンバーシップは承認であると同時に義務でもあります。 コンパイラーチームのメンバーには、一般にレビューやその他の作業を行うだけでなく、 維持管理を手助けすることも期待されます。
コンパイラーチームのメンバーになることに関心がある場合、最初に行うべきことは、 いくつかのバグ修正を始めるか、ワーキンググループに参加することです。 バグを見つけるよい方法の 1 つは、 E-easy がタグ付けされた未解決の issue または E-mentor を探すことです。
また、非アクティブのため close された PR の墓場を掘り起こすこともできます。 その中には、まだ有用な作業が含まれているものがあるかもしれません。関連する issue があれば参照してください。 そして、元の作者に時間がなかったために、仕上げだけが必要な場合もあります。
r+ 権限
rustc に対して個別の PR をいくつか作成した後、私たちはしばしば r+ 権限を提供します。 これは、PR をマージするように 「bors」（どの PR を rustc に取り込むかを管理するロボット）へ指示する権利があることを意味します （bors とやり取りする方法についての説明はこちら）。
レビュアー向けのガイドラインは次のとおりです。
- 誰に割り当てられているかに関係なく、どの PR でもいつでもレビューしてかまいません。
ただし、次の場合を除き、PR に r+ しないでください。
- コードのその部分に自信がある。
- 他の誰も先にレビューしたいと思っていないと確信している。
- たとえば、特にデリケートな部分のコードに触れているなどの理由で、 PR が取り込まれる前にレビューしたいという希望を表明する人がいることがあります。
- レビューするときは常に礼儀正しくしてください。あなたは Rust プロジェクトの代表者であるため、行動規範に関しては 期待を上回る対応をすることが求められます。
レビュアーローテーション
r+ 権限を持つと、レビュアーローテーションに追加されることもできます。
triagebot は、受信した PR をレビュアーに自動的に割り当てる bot です。
追加された場合、PR のレビュー担当としてランダムに選ばれます。
自分に割り当てられた PR をレビューすることに不安がある場合は、
r? @so-and-so のようなコメントを残して、他の誰かに割り当てることもできます。
誰に依頼すればよいかわからない場合は、単に r? @nikomatsakis for reassignment と書けば、@nikomatsakis があなたのために誰かを選びます。
レビュアーローテーションに加わることは、私たち全員のレビュー負担を軽減するため、とてもありがたいことです。 ただし、PR に対してタイムリーなフィードバックを人々に返す時間がない場合は、 リストに加わらないほうがよいかもしれません。