이슈 트리아지

이 페이지는 rust-lang/rust 저장소에 관한 내용입니다. rust-lang GitHub 조직에 속한 다른 저장소는 다른 절차를 따를 가능성이 높습니다.

추적 이슈(C-tracking-issue 레이블이 붙은 이슈)는 이 절차에 해당하지 않으며 다르게 처리됩니다.

동기

rust-lang/rust 저장소에는 수천 개의 이슈가 있고, 수백 명이 이 저장소에서 작업하고 있습니다. 모든 사람이 모든 이슈를 확인하고 해결하는 것은 불가능합니다. 트리아지의 목표는 다음과 같습니다.

• 발견 가능성 향상:
  • 이슈가 어떤 팀과 관련될 수 있는지 분류합니다.
  • 회귀에 태그를 제대로 붙이고 추적하도록 합니다.
  • 이슈를 관련된 사람(특히 관련 팀)과 연결합니다.
• 이슈 성격에 대한 1차 대략적 분류:
  • 이 이슈는 버그입니까, 논의입니까, 아니면 사용자 측 문제입니까?
• 이슈가 충분히 조치 가능한지 파악:
  • 보고에 재현 단계, 재현 코드, 빌드/실행 환경 정보와 같은 추가 정보가 필요합니까?
  • 재현 코드를 최소화해야 합니까?
• 적절한 레이블을 붙여 기여자가 이슈를 필터링하기 쉽게 만듭니다.

현실적으로 모든 이슈가 빠르게 해결되고 적절한 사람에게 발견되기를 기대하기는 어렵습니다. 레이블을 붙이면 나중에 참고할 때 이슈 트래커를 더 쉽게 검색할 수 있으므로, 앞으로 사람들이 관련 이슈나 작업하고 싶은 이슈를 더 쉽게 찾을 수 있습니다.

트리아지는 rust-lang/rust에 대한 쓰기 권한이 있는지와 관계없이 누구나 할 수 있습니다. 트리아지 작업은 여러 사람이 동시에 나누어 하기 쉽고 시작하기도 쉬우므로, 모든 분의 참여를 권장합니다.

rust-lang/rust에 대한 쓰기 권한이 필요한 작업으로는 다음과 같은 것들이 있습니다.

• @rustbot transfer를 사용하여 이슈를 rust-lang GitHub 조직에 속한 다른 저장소로 옮기는 것.
• 이슈를 닫는 것.
• @rustbot을 사용하여 쓰기 권한이 필요한 특정 레이블을 붙이는 것(아래의 “레이블 추가 및 제거” 절을 참고하십시오).

쓰기 권한은 없지만 이러한 작업이 필요하다고 판단된다면, t-release/triage Zulip 채널에 새 토픽을 열거나 t-release/triage 채널의 기존 토픽에 해당 이슈의 링크를 담은 댓글을 남기면 됩니다.

초기 트리아지

이슈가 열리면 보통 needs-triage 레이블이 자동으로 붙습니다. 이는 트리아지되지 않은 이슈를 쉽게 발견하고 필터링할 수 있게 하여, 새 이슈가 초기 트리아지 과정(아래에서 설명합니다)을 반드시 거치도록 하기 위함입니다. needs-triage는 초기 점검 단계입니다. 이슈가 이 레이블을 벗어나는 데 드는 노력은 적어야 합니다.

초기 트리아지를 수행하고 needs-triage 레이블을 제거하려면 다음 조건을 충족하거나 고려해야 합니다. 이 조건을 항상 모두 고려하지 못하더라도 괜찮습니다. 이 목록은 모든 경우를 망라하지 않으므로 엄격한 체크리스트가 아니라 지침으로 활용하십시오.

• 이슈는 이해할 수 있는 내용이어야 합니다. 즉, 문제를 제시해야 합니다.
  • 예를 들어 이슈가 Rust 전반에 관한 질문이라면 이슈를 닫고 사용자를 URLO로 안내해야 합니다. 물론 질문에 답해도 되지만, 다음부터는 URLO를 이용하도록 사용자에게 꼭 안내하십시오.
• 이 이슈가 앞서 보고된 이슈와 중복되는지 확인하십시오.
  • 중복이 확실하다면 이 이슈를 이전 이슈의 중복으로 닫으십시오. 이전 이슈의 백링크에서 이 사실이 분명히 드러나는지 확인하거나, 중복 이슈에 명시적으로 링크하십시오.
  • 확실하지 않더라도 다른 이슈와 중복이거나 비슷하거나 관련이 있을 수 있다는 댓글은 남길 수 있습니다.
• 적절한 레이블을 추가하십시오(레이블).
  • 특히 팀 레이블(T-*)과 이슈 분류 레이블(C-*)이 가장 중요합니다. 팀 구성원은 대개 이 레이블을 기준으로 팀과 관련된 사항을 걸러 내기 때문입니다(예: 트리아지 회의 중).
• 이슈에 재현 방법이 없는데 필요하다면(확실하지 않다면 필요한 것으로 봅니다) 재현 방법을 요청하고 S-needs-repro 레이블을 추가하십시오.
• 이슈에 정보가 부족하다면(예: 시스템 정보, 실제로 사용한 정확한 실행 명령) 문제를 재현하는 데 중요한 정보를 제공해 달라고 보고자에게 요청하십시오. S-needs-info 레이블을 추가하십시오.
• 일부 기능 요청은 이슈 트래커에 올리기에 적절하지 않습니다. 작성자를 적절한 채널로 안내하십시오.
  • 표준 라이브러리 API 요청은 라이브러리 팀 절차를 따라야 합니다.
  • 언어 변경은 IRLO 또는 T-lang Zulip 채널(t-lang)로 안내해야 합니다.
• 회귀를 이분 탐색하는 것이 이슈에 도움이 될 수 있다면(확실하지 않다면 도움이 되는 것으로 봅니다) E-needs-bisection을 추가하십시오(또는 직접 이분 탐색을 수행하십시오). 유용한 이분 탐색 도구로는 cargo-bisect-rustc가 있습니다.
  • 이분 탐색이 이루어졌고 그 결과가 설득력 있다면 S-has-bisection을 추가하십시오.
• 보고된 예제가 크거나 복잡하다면(예: 코드가 많거나, 외부 의존성이 많거나, 실제 문제를 가리는 무관한 경고나 오류가 있다면) 예제를 최소화해야 함을 나타내도록 E-needs-mcve를 추가하십시오.
  • 최소한의 완전하고 검증 가능한 예제(MCVE)가 있다면 이슈에 S-has-mcve 태그를 다십시오. 최소화가 올바른지 다시 확인하십시오. 예를 들어 MCVE가 원래 문제를 다루는지, 다른 문제로 바뀌지 않았는지 확인하십시오.
• 이 이슈가 회귀입니까? 그렇다면 regression-untriaged 레이블을 적용하십시오(또는 정확히 어떤 회귀인지 파악하십시오). 일반적으로 이전에는 동작하던 것이 더 이상 동작하지 않는다면 그 이슈를 회귀로 봅니다.
• 이 이슈와 관련된 사람을 알고 있다면 그 사람을 핑하십시오.
  • 예를 들어 ThatPerson이 최근 해당 기능 작업을 많이 해 왔다면 cc @ThatPerson이라고 작성하십시오.
• 이 이슈가 어떤 기능을 사용합니까? 해당하는 F-* 레이블을 추가하십시오. 예: F-const_trait_impl.
• 이 이슈는 기능을 사용하지 않는데도 nightly가 필요합니까? requires-nightly를 추가하십시오.
• 이 이슈는 내부 기능이 필요합니까? requires-internal-features를 추가하십시오.

레이블 추가 및 제거

rust-lang/rust에 쓰기 권한이 없는 사용자는 우회 방법으로 @rustbot을 사용하여 triagebot.toml 설정에서 허용하는 레이블을 추가하거나 제거할 수 있습니다.

쓰기 권한이 있는 사용자는 이슈를 구독하는 모든 사람에게 불필요한 알림이 가지 않도록 레이블을 직접 변경해야 합니다.

예를 들면 다음과 같습니다.

@rustbot label +T-compiler +C-bug +A-linkage +O-macos -needs-triage

전체 레이블 목록을 보려면 이슈 트래커의 검색창 옆에 있는 “labels” 페이지를 확인하십시오.

일부 레이블은 rust-lang/rust에 쓰기 권한이 있는 사용자만 적용할 수 있다는 점에 유의하십시오. 쓰기 권한이 없는 사용자가 사용할 수 있는 레이블을 확인하려면 triagebot.toml의 [relabel] 섹션 아래에 있는 allow-unauthenticated 목록을 참고하십시오.

relnotes 트리아지

relnotes-tracking-issue 레이블이 붙은 이슈의 경우, 릴리스 노트 문구가 정리될 때까지 needs-triage 태그를 제거해서는 안 됩니다.

레이블

이슈에 적용할 수 있는 레이블은 매우 다양합니다. 트리아지에 사용하는 레이블 집합은 필요에 따라 계속 바뀌며, 저희는 이 목록을 최신 상태로 유지하려고 노력합니다. 레이블은 팀 구성원이 적절하다고 판단할 때 수동으로 추가합니다.

• needs-triage: 새로 등록되어 초기 트리아지가 필요한 이슈임을 나타냅니다.
• T-*: 이 이슈와 관련된 하나 이상의 팀을 지정합니다. 예를 들어 T-compiler, T-types, T-libs 등이 있습니다. 자세한 내용은 팀 예시를 참고하십시오.
• WG-*: 이 이슈와 관련된 워킹 그룹을 지정합니다. 예를 들어 WG-debugging이 있습니다.
• PG-*: 이 이슈와 관련된 프로젝트 그룹을 지정합니다. 예를 들어 PG-exploit-mitigations가 있습니다.
• C-*: 레이블의 범주를 지정합니다. 예를 들어 버그, 추적 이슈, 논의 등이 있습니다.
  • C-optimization: 컴파일러가 놓친 최적화에 사용합니다.
  • C-defective-hardware: 저희가 통제할 수 없는 하드웨어 버그에 사용합니다.
  • C-gub: 정의되지 않은 동작과 같은 사용자 오류로 인해 문제가 발생한 경우에 사용합니다.
  • C-discussion: 버그는 아니지만 논의할 가치가 있는 경우에 사용합니다.
  • C-external-bug: 저희에게 영향을 주지만 저희가 직접 통제할 수는 없으면서도 저희 쪽에서 추적할 가치가 있는 소프트웨어 버그에 사용합니다.
• O-*: 타깃별 이슈의 경우, 컴파일 타깃¹ 또는 컴파일 타깃 계열(특히 플랫폼, 즉 아키텍처나 운영 체제)을 지정합니다. 예를 들어 O-macos, O-aarch64, O-windows, O-windows-msvc 등이 있습니다.
  • 가능하면 가장 구체적인 대상 카테고리를 지정하십시오. 예를 들어 이슈가 *-windows-gnu에는 영향을 주지만 *-windows-msvc에는 영향을 주지 않는다면, 일반적인 O-windows보다 O-windows-gnu를 사용하십시오.
• A-*: 이슈와 관련된 영역입니다. 예를 들면 A-linkage, A-patterns, A-diagnostics 등이 있습니다. 이는 이슈를 필터링할 때 특히 유용합니다.
  • A-diagnostics: 진단 이슈 템플릿으로 생성된 이슈에는 A-diagnostics만 있고 C-bug는 없습니다.
• B-*: 블로커인 이슈입니다.
• D-*: 진단 이슈를 위한 레이블입니다.
  • D-diagnostic-infra: 이 이슈는 진단 인프라 자체에 관한 것입니다.
• L-*: 이슈가 특정 린트와 관련된 경우입니다.
  • L-false-positive: 린트가 발동하지 않아야 할 경우에 발동한 경우입니다.
  • L-false-negative: 린트가 발동해야 할 경우를 놓친 경우입니다.
• F-*: 이슈가 특정 기능(대개 불안정한 기능이며, 대개 언어 기능)과 관련된 경우입니다.
• -Z*: 이슈가 특정한 불안정 -Z 컴파일러 플래그와 관련된 경우입니다.
• requires-nightly: 이 이슈는 nightly 채널 컴파일러에만 영향을 주며, beta 또는 stable 채널 컴파일러에는 영향을 주지 않습니다.
• requires-internal-features: 이 이슈는 내부 기능을 필요로 합니다. 이는 보통 컴파일러 MCP 620에 따라 해당 이슈를 닫아야 한다는 뜻입니다.
• regression-*: 회귀인 이슈를 추적하기 위한 레이블입니다.
  • regression-untriaged: 회귀의 성격과 종류가 불분명하며, 추가적인 회귀 트리아지가 필요함을 나타냅니다.
  • regression-from-stable-to-stable: 이전 stable 릴리스에서 회귀가 발생하여, 이미 최신 stable 릴리스 또는 그보다 이전의 stable 릴리스에까지 도달한 경우입니다.
  • regression-from-stable-to-{beta,nightly}: stable 릴리스에서 beta 또는 nightly 채널로 가면서 회귀가 발생한 경우입니다.
• I-*: 이슈의 성격²을 나타내는 여러 레이블입니다.
  • I-ICE: 내부 컴파일러 오류입니다.
  • I-prioritize: 해당하는 경우 긴급도를 나타내는 우선순위 P-*를 지정할 수 있도록 T-compiler/ops가 이 이슈를 추가로 트리아지해야 함을 나타냅니다.
  • I-heavy: 무거운 코드(바이너리 크기)입니다.
  • I-slow: 느린 런타임 성능입니다.
  • I-hang: 오랜 시간이 지나도 컴파일이 완료되지 않는 경우입니다.
  • I-crash: 컴파일러 또는 생성된 코드가 크래시하지만 ICE로 나타나지는 않는 경우입니다. 예를 들면 SIGSEGV나 접근 위반 등이 있습니다.
  • I-unsound: 라이브러리, 컴파일러, 타입 시스템 또는 언어의 건전성 문제입니다.
  • I-compilemem: 컴파일 중 과도한 메모리 사용입니다.
  • I-compiletime: 느린 컴파일 시간입니다.
  • I-{team}-nominated: {team}의 논의 안건으로 상정된 이슈입니다. 예: I-compiler-nominated.
  • I-lang-easy-decision: (레이블을 붙인 사람이 보기에) T-lang에 필요한 결정이 쉽거나 형식적일 것으로 추정됨을 나타냅니다. 이 레이블이 I-lang-nominated를 의미하지는 않는다는 점에 유의하십시오. 레이블을 붙이는 사람이 해당 이슈를 T-lang 논의에 상정하려면 상정 레이블도 함께 붙여야 합니다.
• P-*: 우선순위 레이블입니다. 컴파일러 우선순위 지정 절차에 따라 적용합니다.
• E-*: 참여 요청³으로, 예를 들어 이슈를 최소화하는 작업이 이에 해당합니다.
  • E-mentor: 이 이슈를 도와줄 멘토가 있으므로 처음 시작하기 좋은 이슈입니다. 멘토로 예정된 사람이 실제로 멘토링할 의향과 여유가 있는지 확인하십시오.
  • E-needs-mcve: 이 이슈에는 재현 사례가 있지만 최소화되어 있지 않습니다. 최소화해야 합니다.
  • E-needs-bisection: 이 이슈는 이분 탐색이 필요합니다. 예를 들어 cargo-bisect-rustc를 사용할 수 있습니다.
  • E-needs-investigation: 이 이슈는 근본 원인과 이슈의 성격을 파악하기 위해 추가 조사가 필요합니다.
  • E-needs-design: 이 이슈는 상당한 설계 작업(탐색, 프로토타이핑, 논의 등)이 필요합니다.
  • E-needs-test: 이슈는 수정되었지만 이에 대한 테스트가 추가되지 않았습니다. 누군가 테스트를 추가하면 이슈를 닫을 수 있습니다.
  • E-{easy,medium,hard}: 누군가가 이슈 수정의 난이도를 추정했습니다. 이는 처음 시작하기 좋은 이슈를 찾는 데 도움이 될 수 있지만, 부정확할 수밖에 없습니다.
• S-*: 이슈의 상태를 나타내며, 예를 들어 S-needs-repro 또는 S-needs-info가 있습니다.
  • S-needs-info: 이슈 보고자의 추가 정보가 필요합니다.
  • S-needs-repro: 재현 자료(코드 샘플, 재현 단계 등)가 필요합니다.
  • S-bug-has-test: 이슈에 대한 known-bug 테스트가 rust-lang/rust의 tests/crashes 테스트 스위트나 다른 곳에 있습니다.
  • S-has-bisection: 이분 탐색이 수행되었으며 그 결과가 신뢰할 만합니다.
  • S-waiting-on-LLVM: 업스트림 LLVM PR 또는 수정을 기다리고 있습니다.
  • S-tracking-forever: 닫을 의도가 전혀 없는 추적 이슈입니다.
• beta-nominated: beta로 백포트하도록 상정된 변경 사항을 추적합니다.
• beta-accepted: beta로 백포트하도록 승인된 변경 사항을 추적합니다. 백포트는 보통 T-release가 처리합니다.
• stable-nominated: 포인트 릴리스에 대비해 stable로 백포트하도록 상정된 변경 사항을 추적합니다.
• stable-accepted: stable로 백포트하도록 승인된 변경 사항을 추적합니다. 백포트는 보통 T-release가 처리합니다.
• relnotes: 다음 릴리스의 릴리스 노트에 문서화하도록 제안된 변경 사항입니다
  • triagebot이 새 relnotes 이슈를 생성하도록 합니다(예시)
  • 또한 relnotes 이슈를 표시하여 T-release relnotes 도구가 처리할 수 있도록 합니다
  • 이슈에서 FCP가 시작되는 경우에도 relnotes 이슈가 생성됩니다.
• metabug: 다른 버그들을 추적합니다.

팀 예시

이 섹션에서는 특정 팀에 배정해야 하는 이슈 유형의 예시를 나열합니다.

T-compiler

진단 및 ICE와 같이 컴파일러 구현과 관련된 모든 것입니다.

T-libs

• 라이브러리 함수의 구현 세부 사항 변경
• 라이브러리 문서의 철자, 문법 및 구성 변경
• 함수 및 메서드와 같은 새로운 라이브러리 API
• 불안정 함수의 시그니처 변경
• 특정 상황에서 함수가 특정 오류 코드를 반환함을 보장하는 것과 같은 라이브러리 문서의 의미적 변경
• 새로운 트레이트 구현과 같은 라이브러리 변경으로 인한 타입 추론 손상

T-lang

• 새로운 키워드/언어 기능
• 표준 라이브러리의 키워드 문서 변경

T-spec

• 레퍼런스 변경

T-opsem

• 노미콘 변경
• 원자적 연산의 의미론과 같은 추상 기계의 의미론 변경
• unsafe 포인터 함수 문서 변경
• core::ptr 문서 변경

레이블 생성

• 기존 레이블을 확인하여 중복되지 않도록 하십시오.
• 새 레이블이 관례에서 벗어나거나 논란의 여지가 있을 수 있다면 https://rust-lang.zulipchat.com/#narrow/channel/242269-t-release.2Ftriage/topic/New.20labels에서 논의하십시오. 다른 사람들이 참고할 수 있도록 새 레이블에 대한 코멘트를 남기십시오.

레이블 별칭

별칭을 사용하면 여러 레이블을 한 번에 추가하거나 제거할 수 있습니다. 별칭에 대해 더 알아보려면 관련 문서를 참고하십시오.

Relnotes 이슈

현재 릴리스 노트 이슈에는 기본적으로 needs-triage가 붙습니다. relnotes 트리아지는 보통 충분한 맥락을 알고 있을 때 하는 것이 가장 좋습니다. 맥락을 잘 모른다면 그대로 두십시오.

• 실제 PR과는 관련이 있지만 사용자에게 보이는 실제 relnotes와는 관련이 없는 영역 A-* 레이블을 제거하십시오.
• 관련 없는 T-* 또는 WG-* 레이블은 제거하십시오.
• PR 작성자, 리뷰어 또는 관련 팀 구성원이 relnotes 문구를 확인했거나 변경했다면 needs-triage를 제거하십시오.

내부 컴파일러 오류(ICE) 이슈 트리아지

내부 컴파일러 오류(ICE)가 포함된 이슈는 다음과 같이 처리합니다.

• 이슈에 I-ICE, T-compiler, C-bug 레이블이 붙어 있는지 확인하십시오.
• 이슈가 실제로 ICE인지, 아니면 I-crash나 I-hang으로 분류하는 것이 더 정확한지 확인하십시오.
• 이전 버전(예: 최신 stable)의 Rust에서 발생한 것이라면 다음을 물어보십시오.
  • beta와 최신 nightly에서도 ICE가 재현됩니까?
  • 그보다 오래된 stable이라면 최신 stable에서도 ICE가 재현되는지 물어보십시오.
• 중복 이슈가 있는지 확인하되, 근본적으로 같은 이슈라고 확신할 때만 중복으로 닫으십시오. 관련 이슈나 중복일 수 있는 이슈로 링크만 걸어 두는 편이 좋습니다.
  • ICE 메시지로 검색해 보는 것이 좋은 방법입니다. ICE 메시지가 같아도 근본 원인은 다를 수 있으므로 중복으로 닫을 때는 주의하십시오.
• 재현 코드가 없다면 재현 코드를 요청하는 댓글을 남기고 S-needs-repro를 추가하십시오.
  • 한 달 정도 지나도 재현 코드가 없다면 일반적으로 이슈를 닫아야 합니다.
• 재현 코드가 최소화되어 있지 않다면 E-needs-mcve를 추가하거나 직접 MCVE를 만드십시오. MCVE 절차에 대한 자세한 내용은 “초기 트리아지” 섹션을 참고하십시오.
• 이슈를 일으키는 코드(백트레이스를 확인하십시오!)와 재현 사례의 성격에 따라 A-* 레이블을 추가하십시오(예: 재현 사례가 특이한 트레이트 impl이거나 백트레이스가 rustc_trait_selection을 가리킨다면 A-traits를 추가하십시오).
• 필요에 따라 T-*, WG-*, PG-*, F-*, requires-*, regression-* 레이블을 추가하십시오.
  • 일반적으로 ICE에는 T-compiler 레이블을 붙여야 합니다. 이슈가 타입 시스템(예: 트레이트 솔버)과 관련된 경우 해당 이슈에 T-types 태그도 추가하십시오.
• rustdoc에서 발생한 ICE라면 T-compiler 대신 T-rustdoc를 추가하십시오.

추가 트리아지

초기 트리아지 단계를 거친 이슈(즉, 더 이상 needs-triage 레이블이 없는 이슈)에도 보통 개선할 점이 남아 있습니다. 추가로 붙일 수 있는 레이블이 훨씬 많은 경우가 많습니다(rust-lang/rust에 대한 쓰기 권한이 없다면 이번에도 rustbot을 사용하십시오).

또한 오래된(얼마나 지나야 오래된 것인지 아직 명확한 기준은 없지만 대략 몇 달 정도) S-needs-repro 이슈는 재현 코드 없이 진행할 방법이 없다면 닫을 수 있습니다. 이 작업에는 rust-lang/rust에 대한 쓰기 권한이 필요하지만, 권한이 없다면 Zulip(예: t-release/triage 또는 general)에 이슈 링크를 올리기만 해도 쓰기 권한이 있는 사람이 대신 닫아 줄 수 있습니다.

E-needs-mcve 및 E-needs-bisection 이슈를 살펴보면서 최소화된 재현 코드를 만들거나 (cargo-bisect-rustc를 사용하여) 이슈를 이분 탐색하는 것도 유용합니다.

• 이분 탐색(bisection) 결과를 제공할 때는 이분 탐색 상태 레이블을 조정하십시오: @rustbot label -E-needs-bisection +S-has-bisection.
• MCVE를 제공할 때는 MCVE 상태 레이블을 조정하십시오: @rustbot label -E-needs-mcve +S-has-mcve.

1. O-* 레이블의 O는 원래 운영 체제(OS)를 의미했습니다. ↩

2. I-* 레이블의 I는 원래 중요도(importance)를 의미했습니다. 이 해석은 I-*-nominated 레이블에 가장 잘 들어맞습니다. 그러나 대부분의 I-* 레이블에서는 I를 이슈(종류)로 해석하는 것이 타당합니다. ↩

3. E-* 레이블의 E는 경험(experience)을 의미합니다. ↩