운영

“운영“은 컴파일러 팀의 일부로서, 조직 및 유지보수 업무를 담당하며 전반적으로 일이 진행되도록 돕습니다. T-compiler ops는 Zulip의 #t-compiler/ops에 있습니다.

다음은 반복적으로 수행하는 작업 목록입니다. 이상적으로는 매주 이 목록을 훑어보십시오. 막힌 부분이나 의문이 있다면, 적절한 맥락을 파악한 후 주저하지 말고 주변 사람들에게 핑을 보내십시오. 기여자는 프로젝트의 가장 훌륭한 자원이며(그들의 시간을 소중히 여겨야 합니다), 언제나 도움이 됩니다.

Zulip #t-compiler에서 새 토픽을 열어 특정 주제, 이슈, 풀 리퀘스트에 대한 논의를 시작할 수 있으며, 팀의 합의와 더 많은 관심이 필요한 경우 I-compiler-nominated 레이블을 붙여 회의에서 논의할 수 있습니다(섹션 Meetings 참고).

이슈 정리

• 우선순위를 매겨야 할 이슈: 우선순위 지정을 참고하십시오.
• 담당자가 없는 P-high 이슈: 이상적으로는 이 범주의 이슈에는 담당자가 있어야 합니다(PR이 없는 것은 걸러내십시오). 드문 경우에는 담당자가 없어도 괜찮습니다.
• FCP 상태의 MCP는 10일 이상 seconded 상태인 경우 종료하고, 미해결 우려 사항이 없는지 확인하십시오.
• 열려 있는 MCP 확인: MCP는 프로토콜로, 제안을 컴파일러 팀의 관심으로 가져오기 위한 것입니다. MCP가 지지되거나 지지 부족으로 종료되는 두 결과 중 하나를 향해 나아가고 있는지 확인하십시오. MCP가 seconded되지 않을 것이 명확하거나 방치된 경우, 약 2~3개월 후 그 상태를 문의하고 종료 여부를 평가해도 됩니다. 그렇지 않다면 막힌 상태에서 벗어나도록 도와주십시오.
• 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에는 트리아지 회의와 설계 회의, 두 종류의 회의가 있습니다. 트리아지 회의는 매주 목요일에 열리며(이 저장소에서 Team Compiler 캘린더를 구독할 수 있습니다), 회의 안건 대부분을 생성해주는 도구가 있습니다(자세한 내용은 트리아지 회의 참고). 설계 회의 제안은 T-compiler 저장소에서 진행되며, 정기적인 steering 회의(다음 design 회의 일정이 정해지는 자리) 중에 일정이 잡힙니다. 설계 회의 또한 안건이 필요하며, 주제를 요약하고 관련 문서를 취합하며 관계자를 초대하는 등의 작업이 조금 필요합니다.

주간 트리아지 회의

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

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

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

이상적으로는 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” 공간의 새 HackMD에 내용을 복사하십시오. 이 작업은 컴파일러 팀 관련 문서를 정리하는 과정의 일부입니다. 이 도구는 최신 주간 컴파일러 트리아지 로그도 다운로드합니다. 제대로 되지 않은 경우, 가장 최근의 성능 트리아지 로그를 수동으로 복사하십시오(Zulip에서 제대로 표시되지 않을 부분을 정리하면서).

안건에 수동으로 추가 세부사항을 더하십시오:

• stable/beta 지명에 대한 요약을 추가하십시오(예: 누가 어떤 이유로 백포트를 지명했는지).
• 팀의 결정을 기다리는 PR들에 대한 요약을 추가하십시오(즉, 왜 대기 중인지)
• P-critical/P-high 버그에 대한 초기 소견을 추가하십시오
• 지명된 이슈들에 대한 요약을 추가하십시오(예: 담당자가 누구인지, 왜 지명되었는지 등)
• 리뷰를 가장 오래 기다린 PR들을 채워 넣으십시오
  • 핑이 적절한지 여부는 판단력을 사용하여 결정하십시오(예: 풀 리퀘스트가 실험적인 것이라면 리뷰가 필요 없을 수 있습니다. 마지막 리뷰 활동 이후 얼마나 지났는지, 최근 댓글이 어떤 내용인지 등)

회의 약 2시간 전에, 완성된 안건을 다가오는 회의의 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 목록(모든 팀), 이들을 앞으로 진행시키는 데 도움이 될 만한 것이 있습니까?

유용한 팁

Github 이슈 대시보드

GitHub 이슈 대시보드를 활용하여 커스텀 필터를 생성할 수 있습니다. 이 필터들은 여러 저장소의 이슈와 PR을 함께 집계할 수 있게 해주며, 고급 필터 적용도 허용합니다. https://github.blog/changelog/2025-04-02-github-issues-dashboard-updates/를 참조하십시오.

커스텀 필터 예시

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