Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

제안, 승인 및 안정화

컴파일러에 기여할 때는 실험이나 리팩터링을 진행하기 위한 허가를 받거나 기능을 안정화하는 경우처럼, 피드백과 승인을 받아야 하는 일이 매우 흔합니다. 상당한 규모의 변경 사항이 있다면, 기여자는 리뷰를 위해 제출하기 전에 Zulip에서 팀에 연락하여 해당 변경 사항을 논의할 것을 권장합니다. 이 문서는 컴파일러 팀이 승인 결정을 내리는 데 사용하는 다양한 절차와 각 절차를 언제 사용해야 하는지를 요약하는 것을 목표로 합니다.

승인

팀이 제안을 승인하는 데 사용할 수 있는 메커니즘은 세 가지입니다(모든 승인 메커니즘이 모든 제안 방식에 적합한 것은 아닙니다. 아래를 참조하십시오).

  • r+
    • 제안이 병합 승인을 받으면 r+되었다고 합니다.
    • r+는 PR을 승인하는 데에만 사용할 수 있습니다.
  • 재청(주요 변경 제안에만 해당, 아래 참조)
    • 팀 구성원이 제안을 공식적으로 지지하면 해당 제안은 재청된 것입니다. 재청은 다른 팀 구성원이 우려 사항을 제기할 수 있도록 10일간의 대기 기간을 두는 것을 조건으로 제안을 잠정적으로 수락합니다.
    • MCP에서 final-comment-period 레이블을 제거하여 “재청을 취소“할 수 있습니다.
  • FCP
    • 최종 의견 수렴 기간은 T-compiler 구성원이 시작합니다. 이는 팀으로부터 구체적인 합의를 얻기 위한 도구입니다. 제안을 승인하려면 컴파일러 FCP 리뷰어(compiler-fcp 하위 팀)의 승인을 받은 후 10일간의 대기 기간을 거쳐야 합니다.
    • FCP는 모든 형태의 제안을 승인하는 데 사용할 수 있습니다.

제안

컴파일러 팀에 변경을 제안하는 방법은 세 가지입니다. 어떤 방법이 적절한지는 아래에 설명하는 제안의 성격에 따라 달라집니다.

  • 의견 요청(RFC)
    • RFC는 rust-lang/rfcs 저장소에 대한 풀 리퀘스트이며, 중대한 변경 사항에 한해 사용하는 무거운 제안 메커니즘입니다.
    • RFC 제안은 FCP로만 승인할 수 있습니다.
  • 주요 변경 제안(MCP)(RFC 2904에서 도입)
    • MCP는 rust-lang/compiler-team 저장소의 이슈이며, 대부분의 제안에 적합한 중간 무게의 제안 메커니즘입니다. MCP는 최종 사용자에게 직접 영향을 주지 않는 서면 제안에 권장됩니다.
    • MCP 제안은 FCP 또는 재청(팀 구성원 1인의 지지)으로 승인할 수 있습니다.
  • 풀 리퀘스트(PR)
    • PR은 rust-lang/rust 저장소에 대한 풀 리퀘스트이며, 대부분의 제안에 적합한 가벼운 제안 메커니즘입니다. 제안에 작은 패치 세트가 수반되는 경우(예: 컴파일러 플래그의 안정화 또는 새 타깃 추가)에는 PR이 선호됩니다.
    • PR 제안은 FCP 또는 r+로 승인할 수 있습니다.

MCP는 어떻게 제출합니까?

  • 주요 변경 템플릿을 사용하여 rust-lang/compiler-team 저장소에 추적 이슈를 여십시오.
    • 봇이 #t-compiler/major changes 스트림에 Zulip 토픽을 자동으로 생성합니다.
    • 우려 사항이 제기되면 해당 우려 사항을 해소하도록 제안을 수정하는 것이 좋습니다.
    • 또는 설계 회의 제안을 제출하여 더 길고 집중적인 논의를 진행할 수도 있습니다.
  • 주요 변경 제안이 수락되려면 다음 세 가지가 필요합니다.
    • 재청: 아이디어에 찬성하되 제안을 처음 제기한 사람은 아닌 컴파일러 팀 구성원입니다.
    • 최종 의견 수렴 기간(사람들이 의견을 남길 시간을 주기 위해 10일간 기다리는 기간)입니다.
      • 변경 사항을 쉽게 되돌릴 수 있거나 추가 반대 의견이 나올 가능성이 낮다고 판단되는 경우 FCP를 생략할 수 있습니다. 예를 들어, 사전에 많은 논의가 있었던 경우 이런 일이 자주 있습니다.
      • 해결되지 않은 우려 사항이 있으면 최종 의견 수렴 기간이 완료되지 않습니다.
      • 해결되지 않은 우려 사항이 모두 해결되면 최종 의견 수렴 기간 카운트다운이 다시 시작됩니다.
  • FCP가 완료된 후 해결되지 않은 우려 사항이 없으면 기여를 시작할 수 있습니다.
    • 이전에 수락된 MCP가 이후에 필요한 승인을 대신하지는 않습니다.

compiler-team 저장소의 MCP에는 어떤 종류의 댓글을 남겨야 합니까?

기술적인 대화는 Zulip 스트림에서 진행하십시오. compiler-team 저장소의 이슈는 트래픽이 적게 유지되고 절차적인 목적으로만 사용되도록 의도되었습니다.

제안을 “재청“하려는 팀 구성원은 관련 코드를 잘 알고 있는 것이 좋습니다. 간과해서는 안 될 우려 사항은 누구나 지적할 수 있습니다.

우려 사항을 제기한 팀 구성원은 이후 제안이 변경되면 후속 조치를 하고 해당 우려 사항을 해소해야 합니다.

반대 의견은 어떻게 제기합니까?

이러한 절차적인 댓글은 이슈에 남길 수 있습니다(Zulip에도 메시지를 남기는 것이 좋습니다). 이전 절을 참고하십시오. 우려 사항은 진행을 막는다는 점을 기억하는 것이 중요합니다. 따라서 우려 사항은 가능한 한 빨리, 그리고 가장 명확한 방식으로 등록해야 합니다(등록되지 않은 “가벼운 우려 사항“은 진행을 막는 것으로 간주하지 않습니다).

기계가 우려 사항을 파싱하여 확인할 수 있도록 다음 문법을 사용하여 우려 사항을 공식적으로 등록하십시오.

@rustbot concern reason-for-concern

<long description of the concern>

그리고 우려 사항이 해결되면 다음 문법을 사용하여 해제하십시오.

@rustbot resolve reason-for-concern

MCP는 어떻게 재청합니까?

일반적으로 MCP를 승인(재청)하기 전에 약간의 시간(예를 들어 며칠)을 기다려 서로 다른 시간대와 근무 일정을 가진 사람들이 살펴볼 수 있도록 하는 것이 좋습니다. 단, 제안이 매우 간단하고 명확하여 고민할 필요 없이 승인할 수 있는 경우는 예외입니다.

MCP는 다음을 사용하여 재청할 수 있습니다.

@rustbot second
우려 사항이 해결되지 않았는지는 누가 결정합니까?

보통은 해당 분야의 전문가들이 합의에 이르지만, 가부 동수를 해소하기 위한 투표나 판단이 필요한 경우에는 컴파일러 팀 리드가 최종 결정을 내립니다.

MCP는 언제 닫아야 합니까?

MCP는 다음과 같은 경우에 닫힐 수 있습니다.

  • 작성자가 더 이상 제안을 추진할 의사가 없는 경우 작성자가 닫을 수 있습니다. 이런 경우 MCP 작성자가 직접 제안을 닫아 주시면 정리 상태를 유지하는 데 도움이 되므로 감사하겠습니다
  • 팀의 핵심 구성원들이 강하게 반대하고 그 반대가 해소될 가능성이 낮아 보이는 경우 팀 리드나 전문가가 닫을 수 있습니다.
  • 약 3개월 동안 활동이 없는 경우 트리아지를 담당하는 사람이 닫을 수 있습니다. 이 경우 이슈를 “되살리고” 싶다면 누구든 부담 없이 다시 열어도 됩니다.

승인이 필요한 기여를 승인 없이 제출하면 어떻게 됩니까?

해당 기여에 필요한 승인이 MCP나 RFC를 요구한다면, 먼저 MCP나 RFC를 작성해 달라고 요청하면서 기여를 닫거나 차단됨으로 표시해야 합니다. 해당 기여에 PR 승인만으로 충분하다면(아래 참조) 승인 절차를 시작할 수 있습니다.

승인을 받기 전에 실험적으로 코드 작업을 해도 됩니까?

물론입니다! 자유롭게 PR 작업을 하거나 코드를 작성해도 됩니다. 다만 그러한 PR은 실험적인 것으로 표시해야 하며, 병합되어서는 안 되고, (원하는 사람이 있는 경우가 아니라면) 누구에게도 리뷰를 기대해서는 안 됩니다. 또한 팀이 제안을 어떻게 받아들이는지 분위기를 파악해 보십시오. 제안을 보여 주는 코드는 환영하지만, 동시에 승인되지 않을 수도 있는 작업에 시간을 들이지 않기를 바랍니다. 따라서 개념 증명이나 더 정교한 패치가 승인에 도움이 될 수는 있어도 승인을 보장하지는 않는다는 점을 유념하십시오.

좋은 제안의 조건은 무엇입니까?

좋은 제안은 다음 내용을 다룹니다.

  • 동기: 이 제안이 왜 필요합니까? 어떤 문제를 해결합니까? 그 문제가 왜 중요합니까?
  • 설계: 무엇을 제안합니까?
  • 구현 참고 사항: 보통은 구현에 대해 이야기할 필요가 없지만, 특별히 짚어야 할 사항이 있다면(예: 구현이 매우 침습적이었다면) 여기에 적을 수 있습니다.
  • 선례, 링크 및 관련 자료: clang이나 lld 같은 다른 컴파일러/링커/도구에 비슷한 제안이 있었습니까?
  • 대안, 우려 사항 및 주요 결정: 검토한 대안이 있었습니까? 있었다면 왜 이 설계를 선택했습니까?

어떤 제안/승인이 필요합니까?

이 절에서는 각 상황에 어떤 제안과 승인이 필요한지 빠짐없이 자세히 설명합니다.

내부

  • 알림 그룹 만들기
    • 제안 방법: PR
    • 승인 방법: r+
    • 팀 구성원이 새 그룹이 타당하다고 판단하면 그룹을 추가하는 변경 사항을 병합할 수 있습니다.
  • 중요한 내부 리팩터링/변경
    • 제안 방법: MCP
    • 승인 방법: 재청
    • 제안하는 리팩터링을 MCP에 자세히 설명하십시오. 더 집중적인 논의가 필요하다면 스티어링 회의를 잡을 수도 있습니다. 논의가 마무리되면 팀 구성원이 제안을 재청할 수 있습니다.
  • 소규모 팀 정책 정의/변경
    • 제안 방법: MCP
    • 승인 방법: 재청
    • MCP로 충분한 소규모 정책 변경의 예로는 대소문자를 구분하지 않는 파일 시스템에 대한 지원 수준이나, 팀이 추적 이슈를 논의의 장으로 삼을지 여부 등이 있습니다.
  • 대규모 팀 정책 정의/변경
    • 제안 방법: RFC
    • 승인 방법: FCP
    • FCP가 필요한 대규모 정책 변경에는 팀 구조와 구성원 자격 기준 등에 대한 제안이 포함됩니다.

컴파일러 플래그

  • 내부 전용 컴파일러 옵션 추가(예: -Ztreat-bug-as-err)
    • 제안 방법: PR
    • 승인 방법: r+
    • 팀 구성원이 새 옵션이 타당하다고 판단하면 해당 옵션을 추가하는 변경을 병합할 수 있습니다.
  • 추후 안정화를 목표로 하는 단순한 컴파일러 옵션 추가
    • 제안 방법: MCP
    • 승인 방법: 재청
    • LLVM의 논란의 여지가 없는 옵션을 노출하는 것과 같은 단순한 옵션은 재청된 MCP와 리뷰어의 r+ 승인으로 구현하고 병합할 수 있습니다. 추후 안정화할 때는 정식 FCP가 필요합니다.
  • 추후 안정화를 목표로 하는 복잡한 컴파일러 옵션 추가
    • 제안 방법: RFC
    • 승인 방법: FCP
    • 옵션이 복잡하고 설계상의 고려가 필요하다면 t-compiler RFC를 작성하여 제출하십시오.
  • 내부 전용 플래그 제거
    • 제안 방법: MCP
    • 승인 방법: 재청
    • 불안정 구현을 제거하는 근거를 설명하십시오. 논의가 마무리되면 팀 구성원이 제안을 재청할 수 있습니다.
  • 최종적으로 안정화할 예정이었던 플래그 제거
    • 제안 방법: MCP
    • 승인 방법: 재청
    • 불안정 구현을 제거하는 근거를 설명하십시오. 논의가 마무리되면 팀 구성원이 제안을 재청할 수 있습니다
  • 컴파일러 옵션 안정화
    • 제안 방법: PR
    • 승인 방법: FCP
    • PR을 열고 안정화 가이드를 따르십시오. 배정된 리뷰어가 안정화 가이드를 따랐는지 확인하고 코드를 리뷰한 뒤 FCP를 시작합니다
  • 컴파일러 옵션 안정화 되돌리기
    • 제안 방법: PR
    • 승인 방법: FCP
    • PR을 열고 안정화 가이드를 따르십시오. 배정된 리뷰어가 안정화 가이드를 따랐는지 확인하고 코드를 리뷰한 뒤 FCP를 시작합니다
  • stable 플래그의 동작 확장
    • 제안 방법: MCP
    • 승인 방법: 재청
    • 플래그의 동작을 확장하는 근거를 설명하십시오. 논의가 마무리되면 팀 구성원이 제안을 재청할 수 있습니다

속성

  • 내부 전용 속성 추가(예: rustc_attrs)
    • 제안 방법: PR
    • 승인 방법: r+
    • 팀 구성원이 새 속성이 타당하다고 판단하면 해당 속성을 추가하는 변경을 병합할 수 있습니다
  • 향후 안정화를 목표로 하는 속성 추가
    • 언어 팀의 절차를 따르고 구현 PR은 컴파일러 팀 구성원의 리뷰를 받으십시오
  • 내부 전용 속성 제거
    • 제안 방법: MCP
    • 승인 방법: 재청
    • 불안정 구현을 제거하는 근거를 설명하십시오. 논의가 마무리되면 팀 구성원이 제안을 재청할 수 있습니다
  • 최종적으로 안정화하는 것을 목표로 했던 속성 제거
    • 언어 팀의 절차를 따르고, 제거 PR은 컴파일러 팀 구성원의 리뷰를 받으십시오
  • 속성 안정화
    • 언어 팀의 절차를 따르고, 안정화 PR은 컴파일러 팀 구성원의 리뷰를 받으십시오
  • 속성 안정화 되돌리기
    • 언어 팀의 절차를 따르고, 되돌리기 PR은 컴파일러 팀 구성원의 리뷰를 받으십시오

기능

  • 아직 제안되지 않은 언어 기능의 실험적 구현 추가
    • 제안 방법: MCP
    • 승인 방법: 재청
    • 언어 팀의 승인(해당 기능이 실험해 볼 가치가 있다는 판단)을 받은 뒤 RFC를 제출하십시오. 논의가 끝난 후 컴파일러 팀 구성원이 구현이 실현 가능하고 컴파일러 메인테이너에게 과도한 부담을 주지 않는다는 데 동의하면, 해당 구성원이 MCP를 재청할 수 있으며 구현을 진행할 수 있습니다.
    • 구현 담당자가 컴파일러 팀 구성원인 경우에는 이 절차가 필요하지 않습니다
  • 언어 기능 안정화
    • 언어 팀의 절차를 따르고, 안정화 PR은 컴파일러 팀 구성원의 리뷰를 받으십시오
  • 언어 기능 안정화 되돌리기
    • 언어 팀의 절차를 따르고, 되돌리기 PR은 컴파일러 팀 구성원의 리뷰를 받으십시오

타깃

타깃 티어별 세부 요구 사항은 타깃 티어 정책을 참고하십시오.

타깃 승격

타깃 승격 개요:

현재 타깃 티어목표 타깃 티어제안필요한 승인
해당 없음(새 타깃 제안)3PRr+(컴파일러 리드)
32MCPFCP
21RFCFCP
  • 새 타깃 제안하기
    • 제안 방법: PR
    • 승인 방법: r+ (컴파일러 리드)
    • PR에 r? compiler_leads를 남기면 컴파일러 리드 중 한 명을 무작위로 리뷰어로 지정할 수 있습니다.
    • 새 타깃을 추가하는 PR을 (관련 문서 업데이트와 함께) 여십시오. PR 설명에는 이 타깃이 타깃 티어 정책을 준수한다는 점을 문서화하십시오.
    • 새 타깃은 반드시 Tier 3에서 시작해야 합니다.
    • 새 타깃은 컴파일러 팀 공동 리드에게 배정해야 합니다. 공동 리드는 라이선스 관련 우려 사항이 있는지 확인합니다. 또한 해당 타깃이 프로젝트 인프라에 요구하는 사항이 있다면 이를 검토하고 관련 팀과 함께 확인합니다.
  • 타깃을 Tier 3에서 Tier 2로 승격하기
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 해당 타깃에 대한 MCP를 여십시오. MCP 설명에는 이 타깃이 Tier 2 타깃 정책을 준수한다는 점을 문서화하십시오.
  • 타깃을 Tier 2에서 Tier 1로 승격하기
    • 제안 방법: RFC
    • 승인 방법: FCP
    • 해당 타깃에 대한 RFC를 여십시오. RFC 본문에는 이 타깃이 Tier 1 타깃 정책을 준수한다는 점을 문서화하십시오.

타깃 강등 또는 제거

타깃 강등 및 제거 요약:

현재 타깃 티어목표 타깃 티어제안필요한 승인
12 (또는 제거)RFCFCP
23 (또는 제거)MCPFCP
3해당 없음(티어 3 타깃 제거)PRr+(컴파일러 리드)
  • 타깃을 티어 1에서 티어 2로 강등하거나 티어 1 타깃을 제거하는 경우
  • 타깃을 티어 2에서 티어 3으로 강등하거나 티어 2 타깃을 제거하는 경우
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 대상 타깃과 근거를 담은 MCP를 여십시오.
  • 티어 3 타깃 제거
    • 제안 방법: PR
    • 승인 방법: r+(컴파일러 리드)
    • 제거할 티어 3 타깃과 제거 근거를 담은 PR을 여십시오.

기타 타깃 변경

  • 티어 3 타깃의 이름을 바꾸거나 호환성을 깨는 변경을 하는 경우
    • 제안 방법: PR
    • 승인 방법: r+
    • 제안하는 새 이름을 담은 PR을 열어 변경 동기를 설명하고 리뷰어에게서 r+를 받으십시오.
  • 티어 2 타깃의 이름을 바꾸거나 호환성을 깨는 변경을 하는 경우
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 변경 동기를 설명하는 MCP를 열고, 승인을 위해 FCP를 시작하십시오.
    • 승인되면 변경 사항을 알리는 블로그 게시물을 함께 발행해야 하며, 변경이 적용되기 전에 최소 한 번의 릴리스에 해당하는 사전 공지 기간을 두어야 합니다.
  • 티어 2 타깃의 호스트 도구 상태 변경(호스트 도구 없음 => 호스트 도구 있음, 호스트 도구 있음 => 호스트 도구 없음)
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 변경 동기를 설명하는 MCP를 열고, 승인을 위해 FCP를 시작하십시오.
  • 티어 1 타깃의 이름을 바꾸거나 호환성을 깨는 변경을 하는 경우
    • 제안 방법: RFC
    • 승인 방법: FCP
    • 변경 동기를 설명하는 RFC를 열고, 승인을 위해 FCP를 시작하십시오.
    • 승인되면 변경을 알리는 블로그 게시물을 함께 게시해야 하며, 변경이 적용되기 전에 최소 한 릴리스의 예고 기간을 두어야 합니다.
  • 티어 1 타깃의 호스트 도구 지원 여부 변경(호스트 도구 없음 => 호스트 도구 있음, 호스트 도구 있음 => 호스트 도구 없음)
    • 제안 방법: RFC
    • 승인 방법: FCP
    • 변경 동기를 설명하는 RFC를 열고, 승인을 위해 FCP를 시작하십시오.
    • 승인되면 변경을 알리는 블로그 게시물을 함께 게시해야 하며, 변경이 적용되기 전에 최소 한 릴리스의 예고 기간을 두어야 합니다.
    • 호스트 도구 지원을 중단하는 경우, 부득이하게 한 릴리스의 유예 기간을 생략해야 할 때도 있습니다.
  • 타깃 기준선 변경(예: 최소 Darwin 또는 Windows 버전 상향)
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 타깃의 기준선을 변경해야 하는 이유를 설명하는 MCP를 작성하십시오. 논의가 마무리되면 기준선 변경을 승인하기 위한 FCP를 시작할 수 있습니다.
  • 타깃 메인테이너 추가/제거
    • 제안 방법: PR
    • 승인 방법: r+
    • 타깃 문서 변경 사항을 담은 PR을 열고 리뷰어로부터 r+를 받으십시오.
  • 타깃 기능 추가
    • 제안 방법: PR
    • 승인 방법: r+
    • 타깃 기능을 추가하는 PR을 열고 리뷰어로부터 r+를 받으십시오.
  • 타깃 기능 안정화
    • 제안 방법: PR
    • 승인 방법: FCP
    • 타깃 기능을 안정화하는 PR을 여십시오. 리뷰어가 변경 사항에 만족하면 FCP를 시작할 수 있습니다.

린트, 오류 및 경고

  • 새 경고/오류 추가
    • 제안 방법: PR
    • 승인 방법: r+
    • 구현을 담은 PR을 열고 리뷰어로부터 r+를 받으십시오.
  • 새 린트 그룹 추가
    • 언어 팀의 절차를 따르고, 구현 PR은 컴파일러 팀 구성원에게 리뷰를 받으십시오
  • 컴파일러 기능과 관련된 새 린트 추가
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 컴파일러 플래그처럼 원래 컴파일러 팀의 소관인 세부 사항에 관한 린트는 언어 팀이 아니라 컴파일러 팀이 승인합니다.
    • 린트와 그 근거를 설명하는 MCP를 작성하십시오. 논의가 마무리되면 새 린트를 승인하기 위한 FCP를 시작할 수 있습니다
  • 컴파일러 기능과 관련된 새 향후 호환성 경고(FCW) 추가
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 컴파일러 플래그처럼 원래 컴파일러 팀의 소관인 세부 사항에 관한 FCW는 언어 팀이 아니라 컴파일러 팀이 승인합니다.
    • FCW와 그 근거를 설명하는 MCP를 작성하십시오. 논의가 마무리되면 새 FCW를 승인하기 위한 FCP를 시작할 수 있습니다
  • 컴파일러 기능과 관련된 린트의 기본 린트 수준 변경
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 컴파일러 플래그처럼 원래 컴파일러 팀의 소관인 세부 사항에 관한 린트는 언어 팀이 아니라 컴파일러 팀이 승인합니다.
    • 기본 린트 수준을 변경하려는 근거를 설명하는 MCP를 작성하십시오. 논의가 마무리되면 새 린트를 승인하기 위한 FCP를 시작할 수 있습니다
  • 언어 기능과 관련된 새 린트 추가
    • 언어 팀의 절차를 따르고, 구현 PR은 컴파일러 팀 구성원에게 리뷰를 받으십시오
  • 언어 기능과 관련된 새 향후 호환성 경고(FCW) 추가
    • 언어 팀의 절차를 따르고, 구현 PR은 컴파일러 팀 구성원에게 리뷰를 받으십시오
  • 언어 기능과 관련된 린트의 기본 린트 수준 변경
    • 언어 팀의 절차를 따르고, 구현 PR은 컴파일러 팀 구성원에게 리뷰를 받으십시오

라이선스

  • 새 의존성 도입/라이선스 변경/의존성 버전 올리기
    • 제안 방법: PR
    • 승인 방법: r+ (컴파일러 리드)
    • 라이선스에 영향을 주는 변경 사항으로 PR을 열고, 팀 리드에게 리뷰를 배정하십시오

컴파일러 변경 사항의 stable/beta 채널 백포트 상정

백포트를 참조하십시오.

rust-lang/rust CI에 생태계/통합 테스트 작업/구성 요소 추가

rust-lang/rust CI에 생태계/통합 테스트 작업/구성 요소 추가를 참조하십시오.