운영

“운영“은 컴파일러 팀의 일부로, 조직 및 유지 관리 업무를 맡으며 전반적으로 일이 원활하게 진행되도록 돕습니다. T-compiler 운영 팀은 Zulip의 #t-compiler/ops에서 활동합니다.

다음은 정기적으로 수행하는 작업 목록입니다. 가능하면 매주 이 목록을 점검하십시오. 진행을 가로막는 문제나 의문점이 있다면 적절한 맥락을 파악한 뒤 주저하지 말고 관련된 사람들에게 핑을 보내십시오. 기여자는 프로젝트의 가장 소중한 자원이며(그러므로 우리는 그들의 시간을 배려하고자 합니다) 언제나 기꺼이 도와줍니다.

특정 주제, 이슈 또는 풀 리퀘스트에 대한 논의는 Zulip의 #t-compiler에 새 토픽을 열어 시작할 수 있으며, 합의가 필요하고 팀이 더 집중해서 다뤄야 하는 경우에는 I-compiler-nominated 레이블을 붙여 회의에서 논의할 수 있습니다(회의 절 참조).

이슈 관리

• 우선순위를 지정해야 할 이슈: 우선순위 지정을 참조하십시오.
• 담당자가 없는 P-high 이슈: 이 범주의 이슈에는 가능하면 담당자가 있어야 합니다(PR이 없는 이슈만 걸러 내십시오). 드물게는 담당자가 없어도 괜찮습니다.
• FCP 상태인 MCP: 재청된 지 10일이 넘은 MCP를 종료하되, 해결되지 않은 우려 사항이 없는지 확인하십시오
• 열린 MCP 확인: MCP는 제안을 컴파일러 팀에 알리기 위한 절차입니다. MCP가 재청되거나 재청되지 않아 종료되는 두 결과 중 하나를 향해 진행되고 있는지 확인하십시오. MCP가 재청되지 않을 것이 분명하거나 방치된 경우, 약 두세 달이 지난 뒤에는 상태를 문의하고 종료 여부를 검토해도 됩니다. 그렇지 않은 경우에는 막힌 MCP가 다시 진행되도록 도우십시오.
• MCVE가 필요한 이슈
• FCP가 진행 중인 이슈와 PR: 팀이 체크박스를 표시해야 하는지 확인하십시오. 이 이슈들은 주간 트리아지 회의 안건에 포함됩니다.

T-compiler의 우선순위 지정

우선순위 지정이 어떻게 이루어지는지는 여기를 참조하십시오.

회귀를 살펴볼 때 유용한 필터는 다음과 같습니다.

• 우선순위가 없는 nightly 회귀
• 우선순위가 없는 beta 회귀
• 우선순위가 없는 stable 회귀
• 우선순위가 없고 트리아지되지 않은 회귀

PR 관리

• 모든 PR에는 팀이 지정되어 있어야 합니다
  • 팀 레이블이 없는 PR
  • 작성자 응답 대기 중
  • 리뷰 대기 중

릴리스 일주일 전에 할 일:

• 우선순위가 없는 회귀가 없어야 합니다: 회귀가 수정되었는지 확인하고, 수정되지 않았다면 팀의 관심을 끌도록 노력하십시오.
• 담당자가 없는 beta 회귀나 stable 회귀가 없어야 합니다. PR이 없는 회귀는 걸러 내십시오.
• 작업이 진행 중인 beta 회귀나 stable 회귀가 없어야 합니다. 이상적으로는 모두 병합되어 있어야 합니다.
• 호환성을 깨는 변경(즉, 수용할 수 있다고 합의된 회귀)마다 relnotes-tracking-issue 태그가 붙은 이슈가 있는지 확인하십시오. 릴리스 노트 목록을 참고하십시오. 그러면 T-release가 이를 가져와 릴리스 노트에 추가합니다.

릴리스 이후

• 어떤 회귀를 “수용됨“으로 닫을 수 있는지 신중하게 확인하십시오. 회귀를 일으킨 PR이 호환성을 깨는 변경으로 수용되었음을 밝히는 댓글을 추가하십시오. 예: “PR #123456이 릴리스 노트에 언급될 예정이므로 닫습니다”. 이 관행에 대한 논의와 의견은 Zulip에서 나눌 수 있습니다.

회의

T-compiler에는 트리아지 회의와 설계 회의, 두 종류의 회의가 있습니다. 트리아지 회의는 매주 목요일에 열리며(이 저장소에서 컴파일러 팀 캘린더를 구독할 수 있습니다), 회의 안건 대부분을 생성하는 도구가 있습니다(자세한 내용은 트리아지 회의를 참고하십시오). 설계 회의 제안은 T-compiler 저장소에서 진행됩니다. 일정은 정기적으로 열리는 운영(steering) 회의에서 잡힙니다. 다음 설계 회의 일정도 이 회의에서 정합니다. 설계 회의에도 안건이 필요합니다. 또한 주제를 요약하고, 문서를 취합하고, 관련자를 초대하는 등의 작업도 어느 정도 필요합니다.

주간 트리아지 회의

먼저 관련 이슈에 T-compiler 레이블이 붙어 있는지 확인하십시오:

• I-prioritize 레이블이 붙은 이슈
• stable 릴리스 채널 백포트에 상정된 풀 리퀘스트
• beta 릴리스 채널 백포트에 상정된 풀 리퀘스트
• I-compiler-nominated 레이블이 붙은 이슈(즉, T-compiler의 논의가 필요한 이슈)
• 팀의 피드백을 기다리는 풀 리퀘스트
• 우선순위가 P-high로 분류된 이슈
• 우선순위가 P-critical로 분류된 이슈

..그리고 우선순위 지정이 완료되었는지 확인하십시오. I-prioritize 레이블이 붙은 회귀는 우선순위 평가를 기다리고 있다는 뜻입니다. 이 레이블이 이슈에 추가되면 triagebot이 #t-compiler/prioritization/alerts Zulip 채널로 알림을 보냅니다.

이상적으로는 I-prioritize 레이블이 붙은 모든 T-compiler 이슈에 우선순위가 지정되어 있어야 합니다. 그렇지 않다면 이 목표에 도달하도록 노력하십시오. 때로는 여러 요인 때문에 이슈에 우선순위 레이블을 지정하지 못하기도 합니다. 보고 내용이나 맥락이 불분명한 경우도 있고, 재현할 수 없어 MCVE가 있으면 도움이 되는 경우도 있습니다. 이슈 보고자나 다른 기여자에게 주저하지 말고 설명을 요청하십시오.

stable, beta, nightly를 리뷰하고 가능하면 담당자가 배정되도록 하십시오.

안건을 생성하기 전 마지막 단계는 주요 변경 제안(MCP)을 수락하는 것이며, 이 작업은 보통 자동화되어 있습니다. 최종 의견 수렴 기간(FCP) 단계(final-comment-period 레이블이 붙어 있는 것으로 식별됨)에 10일 넘게 머물러 있는 MCP는 수락할 수 있습니다. MCP에 해결되지 않은 우려 사항이 없다면(has-concerns 레이블을 확인하십시오) final-comment-period 레이블을 제거하고 major-change-accepted 레이블을 추가한 뒤 이슈를 닫으면 됩니다.

마지막으로 회의 안건을 생성할 수 있습니다. triagebot을 클론하여 빌드한 뒤 다음을 실행하십시오:

$ cargo run --bin prioritization-agenda

내용을 “Rust Lang Compiler Team”(Rust 언어 컴파일러 팀) 공간의 새 HackMD 문서에 복사하십시오. 이 도구는 최신 주간 컴파일러 트리아지 로그도 내려받습니다. 이 작업이 제대로 되지 않았다면 가장 최근의 성능 트리아지 로그를 직접 복사하십시오(약간 정리하여 Zulip에서 잘 표시되지 않을 내용은 제거하십시오).

안건에 다음 세부 사항을 직접 추가하십시오:

• stable/beta 상정 건의 요약을 추가하십시오(예: 누가 백포트를 상정했고 그 이유는 무엇인지).
• 팀의 응답을 기다리는 PR의 요약을 추가하십시오(즉, 왜 대기 중인지).
• P-critical/P-high 버그에 대한 초기 소견을 추가하십시오.
• 상정된 이슈의 요약을 추가하십시오(예: 담당자가 누구인지, 왜 상정되었는지 등).
• 리뷰를 기다리는 가장 오래된 PR 목록을 채우십시오.
  • 핑을 보내는 것이 적절한지 판단하십시오(예: 풀 리퀘스트가 실험용이라면 리뷰가 필요하지 않을 수도 있습니다. 마지막 리뷰 활동 이후 얼마나 지났는지, 최근 댓글 내용은 어떠한지도 살펴보십시오).

회의 약 두 시간 전에 다가오는 회의의 Zulip 스레드에 완성된 안건을 공지하고 공유하십시오(스레드가 아직 없다면 새로 만드십시오):

Hello @*T-compiler/meeting*, triage meeting in about 2h.
Pre-triage done in #**t-compiler/prioritization/alerts**.
Meeting agenda [on HackMD](https://hackmd.io/aaabbbccc123456)

GitHub에서 이슈 상태가 바뀌었을 수 있으므로, 생성기를 다시 실행하여 새로운 세부 사항을 안건에 옮겨 적는 것을 항상 권장합니다.

회의가 끝난 후에는 몇 가지 마무리 작업이 있습니다:

• HackMD에서 쓰기 권한을 Owners에게 부여하여 안건을 잠그십시오.
• MCP에서 to-announce 레이블을 제거하십시오. 단, 이 레이블이 바로 회의 도중에 추가된 경우(따라서 다음 회의에서 다뤄질 경우)는 예외입니다.
• rust-lang/rust, compiler-team, forge에서 to-announce FCP를 제거하십시오. 회의 도중의 변경 사항에 관해서는 앞과 동일한 단서가 적용됩니다.
• 회의에서 수락된 beta nominated 및 stable nominated 백포트를 수락하거나 거절하십시오. 자세한 내용은 t-release 백포트 문서를 확인하십시오.
  • 백포트를 수락하려면 {beta,stable}-accepted 레이블을 추가하고 {beta,stable}-nominated 레이블은 그대로 두십시오. 다른 자동화 절차가 이 풀 리퀘스트들을 처리하므로 두 레이블을 모두 남겨 두는 것이 중요합니다. GitHub에 Zulip 논의 링크를 담은 댓글을 추가하십시오.
  • 백포트를 거절하려면 {beta,stable}-nominated 레이블을 제거하기만 하면 됩니다. GitHub에 백포트가 거절된 이유를 설명하는 댓글을 추가하고 Zulip 논의 링크를 첨부하십시오.
• 논의된 이슈에서 I-compiler-nominated 레이블을 제거하십시오. (시간 제약 때문에) 상정된 이슈가 모두 논의되지 못하고 다음 회의로 넘어가는 경우도 있습니다.

P-high 이슈 트리아지 회의

약 6개월마다 P-high 레이블이 붙은 열린 이슈의 큐를 리뷰합니다(지난 회의 목록은 여기에 있습니다). 이 회의의 목표는 이러한 P-high 이슈의 우선순위를 재평가하는 것입니다. 이러한 이슈는 여러 이유로 우선순위가 낮아질 수 있습니다(너무 많은 P-high 이슈가 너무 오래 남아 있으면 배경 소음이 되어 실제로 우선순위가 높은 이슈를 가리게 됩니다).

안건을 생성하는 데에는 이 도구를 사용합니다.

트리아지 회의록은 이후 HackMD에 업로드됩니다.

다른 팀 현황

이 필터들은 다른 팀에서 어떤 일이 진행되고 있는지 확인하기 위한 것입니다

• 팀이 제안을 논의하거나 검토하기를 기다리고 있는 열린 RFC 목록(모든 팀)입니다. 이 RFC들이 진행되도록 도울 수 있는 일이 있습니까?

유용한 팁

GitHub 이슈 대시보드

GitHub 이슈 대시보드를 활용하여 사용자 지정 필터를 만들 수 있습니다. 이 필터를 사용하면 여러 저장소의 이슈와 PR을 한데 모아 볼 수 있으며, 고급 필터도 적용할 수 있습니다. https://github.blog/changelog/2025-04-02-github-issues-dashboard-updates/를 참고하십시오.

사용자 지정 필터 예시

주로 rust-lang/rust를 대상으로 합니다