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을 승인하는 데만 사용할 수 있습니다.
  • 세컨딩(Seconding, 주요 변경 제안에만 해당, 아래 참조)
    • 제안은 팀 구성원이 공식적으로 지지할 때 세컨딩됩니다. 세컨딩은 다른 팀원들이 우려 사항을 제기할 수 있도록 10일간의 대기 기간을 조건으로 제안을 잠정적으로 수락하는 것입니다.
    • MCP에서 final-comment-period 레이블을 제거하여 “언세컨드(unsecond)“할 수 있습니다.
  • 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는 어떻게 제출합니까?

  • major change template을 사용하여 rust-lang/compiler-team 저장소에 추적 이슈를 여십시오.
    • #t-compiler/major changes 스트림의 Zulip 토픽이 봇에 의해 자동으로 생성됩니다.
    • 우려 사항이 제기되면 이를 해소하기 위해 제안을 수정하고 싶을 수 있습니다.
    • 또는 design meeting proposal을 제출하여 더 길고 집중적인 논의를 진행할 수도 있습니다.
  • 승인되려면 주요 변경 제안에는 세 가지가 필요합니다:
    • 동의자(second) — 아이디어를 승인하지만 제안을 처음 낸 사람은 아닌 컴파일러 팀 구성원입니다.
    • 최종 의견 수렴 기간(사람들이 의견을 남길 시간을 주기 위한 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에는 실험적임을 표시해야 하며, (원하는 사람이 있지 않은 한) 머지되어서도 안 되고 누군가 리뷰할 것으로 기대되어서도 안 됩니다. 또한 팀이 해당 제안을 어떻게 느끼는지 파악해 보십시오. 제안을 보여주는 코드는 감사히 여기지만, 동시에 승인받지 못할 수도 있는 작업에 매달리는 것은 원치 않으므로, 개념 증명(proof-of-concept)이나 더 정교한 패치가 승인을 촉진할 수는 있어도 승인을 보장하지는 않는다는 점을 유념하십시오.

좋은 제안이란 무엇입니까?

좋은 제안은 다음 사항을 다룹니다:

  • 동기(Motivation): 이 제안이 왜 필요합니까? 이것이 어떤 문제를 해결합니까? 그 문제가 왜 중요합니까?
  • 설계(Design): 무엇을 제안하는 것입니까?
  • 구현 노트(Implementation notes): 보통은 구현에 대해 이야기할 필요가 없지만, 언급할 만한 중요한 사항이 있다면(예: 구현이 매우 침습적이었다면) 여기에 적어도 좋습니다.
  • 선례, 링크, 관련 자료(Precedent, links, and related material): clang이나 lld 같은 다른 컴파일러/링커/도구에서 유사한 제안이 있었습니까?
  • 대안, 우려 사항, 핵심 결정(Alternatives, concerns, and key decisions): 고려된 대안이 있었습니까? 있었다면 왜 이 설계를 선택했습니까?

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

이 섹션은 주어진 모든 상황에 대해 어떤 제안과 승인이 필요한지를 빠짐없이 상세히 설명하는 것을 목표로 합니다.

내부

  • 알림 그룹 생성
    • 제안 방법: PR
    • 승인 방법: r+
    • 팀 구성원이 새 그룹이 타당하다고 판단하면 해당 그룹을 추가하는 변경을 병합할 수 있습니다.
  • 중요한 내부 리팩터링/변경 사항
    • 제안 방법: MCP
    • 승인 방식: 세컨딩
    • MCP에 제안하는 리팩터링을 상세히 기술하십시오 - 더 집중적인 논의가 필요하다면 선택적으로 조율 회의(steering meeting)를 예약할 수 있습니다. 논의가 마무리되면 팀 구성원이 제안에 동의(second)할 수 있습니다.
  • 작은 팀 정책 정의/변경
    • 다음을 사용하여 제안: MCP
    • 승인 방식: 세컨딩
    • MCP로 충분한 소규모 정책 변경의 예로는 대소문자를 구분하지 않는 파일 시스템에 대한 지원 수준이나 팀이 추적 이슈에서 논의를 진행할 의도가 있는지 여부 등이 있습니다.
  • 큰 팀 정책 정의/변경
    • 제안 방식: RFC
    • 다음을 사용하여 승인: FCP
    • FCP가 필요한 대규모 정책 변경에는 팀 구조 및 구성원 자격 기준 등에 대한 제안이 포함됩니다.

컴파일러 플래그

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

애트리뷰트

  • 내부 전용 애트리뷰트 추가(예: rustc_attrs)
    • 제안 방법: PR
    • 승인 방법: r+
    • 팀 구성원이 새로운 속성이 합리적이라고 판단하면 해당 속성을 추가하는 변경을 병합할 수 있습니다.
  • 추후 안정화를 염두에 둔 애트리뷰트 추가
    • 언어 팀의 프로세스를 따르고 구현 PR을 컴파일러 팀원의 검토를 받도록 합니다
  • 내부 전용 애트리뷰트 제거
    • 다음을 사용하여 제안: MCP
    • 승인 방법: 세컨딩
    • 불안정 구현을 제거하는 근거를 설명합니다. 논의가 마무리되면 팀 구성원이 제안에 동의(second)할 수 있습니다.
  • 궁극적인 안정화를 의도했던 애트리뷰트 제거
    • 언어 팀의 절차를 따르고, 제거 풀 리퀘스트를 컴파일러 팀 구성원에게 검토받으십시오
  • 속성 안정화
    • 언어 팀의 절차를 따르고, 안정화 풀 리퀘스트를 컴파일러 팀 구성원에게 검토받으십시오
  • 속성 안정화 되돌리기
    • 언어 팀의 절차를 따르고, 되돌리기 풀 리퀘스트를 컴파일러 팀 구성원에게 검토받으십시오

기능

  • 아직 제안되지 않은 언어 기능의 실험적 구현 추가
    • 다음을 사용하여 제안: MCP
    • 승인 방법: 동의(Seconding)
    • 언어 팀의 승인(해당 기능이 실험해볼 가치가 있다고 판단하는 것)을 얻은 후 RFC를 제출하고, 논의가 마무리된 뒤 컴파일러 팀 구성원이 구현이 실현 가능하며 컴파일러 메인테이너에게 과도한 부담을 주지 않는다고 동의하면, 해당 구성원이 MCP에 동의(second)하여 구현을 진행할 수 있습니다.
    • 구현의 소유자가 컴파일러 팀 구성원인 경우에는 이 과정이 필요하지 않습니다
  • 언어 기능 안정화
    • 언어 팀의 절차를 따르고, 안정화 풀 리퀘스트를 컴파일러 팀 구성원에게 검토받으십시오
  • 언어 기능 안정화 되돌리기
    • 언어 팀의 절차를 따르고, 되돌리기 풀 리퀘스트를 컴파일러 팀 구성원에게 검토받으십시오

타겟

서로 다른 타겟 티어에 대한 상세한 요구사항은 타겟 티어 정책을 참고하십시오.

타겟 승격

타겟 승격에 대한 간략한 개요:

현재 타겟 티어목표 타겟 티어제안필요한 승인
해당 없음(새 타겟 제안)3풀 리퀘스트r+ (컴파일러 리드)
32MCPFCP
21RFCFCP
  • 새 타겟 제안하기
    • 다음으로 제안: PR
    • 다음으로 승인: r+ (컴파일러 리드)
    • PR에서 r? compiler_leads를 사용하여 컴파일러 리드 중 한 명을 리뷰어로 무작위 배정할 수 있습니다.
    • 새 타겟에 대해(관련 문서 업데이트를 포함하여) PR을 열고, 설명에 타겟 티어 정책 준수 여부를 문서화하십시오.
    • 새 타겟은 반드시 Tier 3로 시작해야 합니다.
    • 새 타겟은 라이선스 관련 우려 사항을 확인하고, 프로젝트 인프라에 대한 요구 사항이 관련 팀들과 함께 검토·확인되도록 하기 위해 컴파일러 팀 공동 리드에게 배정되어야 합니다.
  • Tier 3에서 Tier 2로 타겟 승격하기
    • 다음을 사용하여 제안: MCP
    • 승인 방법: FCP
    • 해당 target으로 MCP를 열고 설명에 Tier 2 target policy를 준수하는지 문서화하십시오.
  • 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
    • 해당 target과 근거를 담아 MCP를 여십시오.
  • 티어 3 타깃 제거
    • 제안 방법: PR
    • 승인 방법: r+ (컴파일러 리드)
    • 티어 3 타깃을 제거하는 대상 타깃과 근거를 담아 PR을 엽니다.

그 외 종류의 타깃 변경

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

린트, 오류 및 경고

  • 새 경고/오류 추가
    • 제안 방법: PR
    • 승인 방법: r+
    • 구현 내용을 담은 PR을 열고 리뷰어로부터 r+를 받으십시오
  • 새 린트 그룹 추가
    • 언어 팀의 프로세스를 따르고, 구현 풀 리퀘스트를 컴파일러 팀 멤버가 검토하도록 합니다
  • 컴파일러 기능과 관련된 새 린트 추가
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 컴파일러 팀의 책임 영역(예: 컴파일러 플래그 등)에 해당하는 세부 사항과 관련된 린트는 언어 팀이 아니라 컴파일러 팀이 승인할 책임이 있습니다.
    • 린트와 그 근거를 설명하는 MCP를 작성하고, 논의가 마무리되면 새 린트를 승인하기 위한 FCP를 시작할 수 있습니다
  • 컴파일러 기능과 관련된 새로운 향후 호환성 경고(FCW) 추가
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 컴파일러 팀의 책임 영역(예: 컴파일러 플래그 등)에 해당하는 세부 사항과 관련된 FCW는 언어 팀이 아니라 컴파일러 팀이 승인할 책임이 있습니다.
    • FCW와 그 근거를 설명하는 MCP를 작성하고, 논의가 마무리되면 새 FCW를 승인하기 위한 FCP를 시작할 수 있습니다
  • 컴파일러 기능과 관련된 린트의 기본 린트 레벨 변경
    • 제안 방법: MCP
    • 승인 방법: FCP
    • 컴파일러 팀의 책임 영역(예: 컴파일러 플래그 등)에 해당하는 세부 사항과 관련된 린트는 언어 팀이 아니라 컴파일러 팀이 승인할 책임이 있습니다.
    • 기본 린트 레벨 변경 근거를 설명하는 MCP를 작성하고, 논의가 마무리되면 새 린트를 승인하기 위한 FCP를 시작할 수 있습니다
  • 언어 기능과 관련된 새 린트 추가
    • 언어 팀의 프로세스를 따르고, 구현 풀 리퀘스트를 컴파일러 팀 멤버가 검토하도록 합니다
  • 언어 기능과 관련된 새로운 향후 호환성 경고(FCW) 추가
    • 언어 팀의 프로세스를 따르고, 구현 풀 리퀘스트를 컴파일러 팀 멤버가 검토하도록 합니다
  • 언어 기능과 관련된 린트의 기본 린트 레벨 변경
    • 언어 팀의 프로세스를 따르고, 구현 풀 리퀘스트를 컴파일러 팀 멤버가 검토하도록 합니다

라이선싱

  • 새 의존성 도입/라이선스 변경/의존성 버전 상향
    • 제안 방식: PR
    • 승인 방식: r+ (컴파일러 리드)
    • 라이선싱에 영향을 미치는 변경 사항으로 풀 리퀘스트를 열고 검토를 위해 팀 리드에게 배정합니다

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

백포트를 참고하십시오.

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

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