서드파티 및 트리 외부 크레이트 정책

이 정책은 컴파일러에서 사용할 트리 외부 크레이트를 만드는 방법과 컴파일러에서 서드파티 크레이트를 사용하는 방법에 관한 지침을 설명합니다.

트리 외부 크레이트

이 정책의 주요 목표 중 하나는 컴파일러에서 사용하는 트리 외부 크레이트(적어도 컴파일러 팀이 관리하며 rust-lang에 있는 크레이트)가 일관된 방식으로 구성되도록 하고, rust-lang/rust와 이들 크레이트 전반에서 동일한 경험을 제공하는 것입니다.

컴파일러의 일부를 언제 트리 외부 크레이트로 분리해야 합니까?

이는 컴파일러 팀 구성원의 재량에 맡기지만, 주간 트리아지 회의에서 안건으로 제기하거나 승인 결정을 활용해 비동기적으로 진행하는 방식으로 팀의 다른 구성원과 논의해야 합니다. 크레이트가 워킹 그룹의 산출물이라면, 트리 외부 크레이트가 적합하다는 데 워킹 그룹 내에서 이미 합의가 이루어져 있어야 합니다.

트리 외부 크레이트를 만들려고 할 때는 크레이트를 얼마나 범용적으로 만들지와, 크레이트가 널리 사용될 경우 늘어날 수 있는 유지 관리 부담 사이에서 균형을 잡는 것이 좋습니다.

컴파일러 크레이트는 어디에 두어야 합니까?

트리 외부 컴파일러 크레이트는 rust-lang 조직에서 호스팅해야 합니다. 이렇게 하면 외부 인프라 도구와의 통합이 간단해지고, GitHub의 기존 팀 권한도 그대로 이어받습니다. 모든 문서에서 컴파일러 팀과 관련 워킹 그룹이 해당 크레이트를 책임진다는 점을 분명히 밝혀야 합니다. 다른 조직이나 개인 저장소에서 프로토타입으로 시작하는 것은 권장하지 않습니다.

개인 계정이나 다른 조직에 있는 기존 트리 외부 크레이트를 이전할 수 있습니까?

네, 이전을 권장합니다. 이전하려면 팀과 논의하고 저장소 이전에 관한 GitHub 문서를 숙지한 뒤 이전을 진행하십시오. 이전이 완료되면 원래 계정이나 조직에 리디렉션이 남게 되며, 이 리디렉션은 이전된 저장소를 새로 포크할 때 그 이름과 충돌합니다. 이 문제를 해결하려면 GitHub에 이메일을 보내야 합니다.

이 크레이트들은 누가 소유합니까?

새 버전이 게시되고 풀 리퀘스트가 리뷰되도록 책임지는 소유자가 분명히 있도록, 컴파일러 팀 구성원이나 워킹 그룹이 크레이트에 대해 느슨한 소유권을 갖는 것이 바람직합니다.

때로는 프로젝트 구성원이 아닌 사람이 크레이트의 주 소유자이고, 주 메인테이너와 더 이상 연락이 닿지 않을 경우에 대비해 컴파일러 팀이 “예비” 메인테이너로 추가되는 경우가 있습니다. 이러한 방식은 권장하지 않지만 사안에 따라 정당화될 수 있습니다.

이 크레이트들의 이름은 어떻게 지어야 합니까?

크레이트 이름은 새 트리 외부 크레이트를 컴파일러 팀에 제안할 때 논의합니다.

크레이트 이름은 사안에 따라 다르게 정합니다. 본질적으로 컴파일러와 밀접하게 연결된 크레이트는 rustc_ 접두사가 붙은 이름을 쓰는 것이 좋습니다. 이는 잠재적 사용자에게 해당 크레이트가 얼마나 stable한지를 나타내는 지표입니다. 더 범용적인 그 밖의 크레이트에는 컴파일러와 무관한 이름을 붙입니다.

트리 외부 크레이트의 리뷰 정책에 제한 사항이 있습니까?

일반적으로 크레이트를 주로 맡는 워킹 그룹과 팀 구성원은 자신들의 그룹에 가장 적합한 방식으로 크레이트를 자유롭게 유지 관리할 수 있지만, 컴파일러와 트리 외부 크레이트 전반에 어느 정도 일관성이 있도록 몇 가지 제한 사항이 있습니다:

• rust-lang/rust에 r+ 권한이 있는 사람은 누구나 PR을 리뷰하고 승인할 수 있어야 합니다.
• 가능하다면 크레이트(또는 관련 워킹 그룹)에 적극적으로 참여하는 사람만 해당 크레이트의 리뷰 로테이션에 포함하면 됩니다.
• 워킹 그룹이나 크레이트 유지 관리에 적극적으로 참여하고 있다면, Rust 전체에 대한 r+ 권한이 없는 사람을 크레이트의 추가 리뷰어로 두어도 괜찮습니다.
• 중요한 풀 리퀘스트는 여러 리뷰어가 리뷰해야 합니다.

트리 외부 크레이트에는 어떤 요건이 있습니까?

트리 외부 크레이트는 반드시 다음 요건을 충족해야 합니다.

• 컴파일러 팀이 유지 관리하는 경우, 달리 해야 할 타당한 이유가 없다면 (컴파일러와 마찬가지로) Apache 2.0과 MIT 이중 라이선스를 적용해야 합니다.
  • 다른 라이선스를 원한다면 새 크레이트를 제안할 때 이 점을 제기하여 컴파일러 팀 구성원의 동의를 받아야 합니다. 달리 요구되는 경우(다른 프로젝트의 코드를 이식하는 경우 등)가 아니라면 tidy가 허용하는 라이선스를 우선적으로 사용하십시오.
• Rust의 행동 강령을 준수해야 합니다.
• 해당 크레이트를 Rust 컴파일러 팀과 관련 워킹 그룹이 유지 관리한다는 사실을 명시해야 합니다.
  • 특히 잠재적 사용자를 위해 예상되는 유지 관리 수준과 안정성을 자세히 기술해야 합니다.
  • 또한 이 저장소에 있는 워킹 그룹 세부 정보로 연결되는 링크도 포함해야 합니다.
• 이 페이지 하단의 목록에 추가되어야 합니다.
• 유의적 버전(semantic versioning)을 따라야 합니다.
• GitHub 병합 큐와 @triagebot을 사용해야 합니다.
• 기존 트리아지 절차와 호환되는 레이블을 사용해야 합니다. 이렇게 하면 트리 외부 크레이트에서 상정된 이슈를 트리아지 회의에서 논의할 수 있습니다.
  • 예: T-compiler, I-compiler-nominated (전체 목록은 추후 결정됩니다)
• 가능하다면 신뢰할 수 있는 게시(trusted publishing)를 사용해야 합니다.
• 컴파일러 팀을 crates.io에서 해당 크레이트의 소유자로 추가해야 합니다.

트리 외부 크레이트를 위한 커뮤니티 인프라가 필요합니까?

트리 외부 크레이트를 위해 커뮤니티 인프라(Zulip 서버/스트림 등)를 만들어야 한다는 요건은 없습니다. 트리 외부 크레이트가 기여자와 사용자로 이루어진 큰 커뮤니티를 얻게 되면 이러한 인프라가 바람직할 수 있지만, 그렇지 않은 경우에는 처음에는 워킹 그룹이나 컴파일러 팀 스트림을 사용해야 합니다.

요청하면 주 Rust Zulip 서버에 이슈와 PR로 자동 링크하는 링크 변환기를 추가할 수 있습니다.

트리 외부 크레이트 작업에 관한 안내가 있습니까?

rustc-dev-guide의 외부 저장소 사용하기를 참고하십시오.

트리 외부 크레이트에서 안정화나 의미 변경은 어떻게 처리해야 합니까?

트리 외부 크레이트의 변경 사항이 언어의 안정화나 의미 변경으로 이어진다면 언어 팀을 참여시키는 것이 중요합니다. rust-lang/rust에 대한 PR에 포함된 서브모듈 변경 사항에는 해당 변경이 rust-lang/rust에 직접 구현된 것과 마찬가지로 적절한 레이블(예: relnotes, t-compiler, t-lang)을 붙여야 하며, 컴파일러나 트리 외부 크레이트에 익숙하지 않은 사람에게 변경 내용이 명확하지 않은 경우 이에 대한 설명을 포함해야 합니다.

트리 외부 크레이트의 릴리스는 언제 해야 합니까?

트리 외부 크레이트에 패치를 병합할 권한이 있는 팀 구성원이라면 누구나 적절하다고 판단할 때 새 릴리스를 만드는 풀 리퀘스트를 생성할 수 있으며, (다른 모든 풀 리퀘스트와 마찬가지로) 다른 팀 구성원의 리뷰를 받기만 하면 됩니다. 새 릴리스는 테스트를 통과하고 새 릴리스를 낼 만한 이유(예: 의존성 업그레이드, 새 기능, 버그 수정 등)가 있는 크레이트 버전이어야 합니다.

저장소에 신뢰할 수 있는 게시가 설정되어 있다면 crates.io에 자동으로 게시되어야 하며, 그렇지 않으면 팀 구성원이 crates.io에 수동으로 게시할 수 있습니다(이를 위한 권한이 있어야 합니다).

요약하면, 트리 외부 크레이트를 만드는 절차는 다음과 같습니다.

1. 필요한 경우 워킹 그룹 내에서 트리 외부 크레이트의 필요성을 논의하고 확인하십시오.
2. 이 문서를 수정하여 아래 목록에 해당 크레이트를 추가하는 PR을 생성하십시오. @rfcbot merge를 사용하여 컴파일러 팀 구성원들의 동의를 얻으십시오.
3. teams 저장소를 사용하여 rust-lang 조직에 새 저장소를 생성하십시오.

   1. 팀이 적절한 권한을 갖도록 access.teams.compiler 키가 'maintain'으로 설정되어 있는지 확인하십시오.

   2. 크레이트의 의도된 목적, 담당 팀과 워킹 그룹(이 저장소에 있는 해당 페이지로 링크), 그리고 의도된 유지 관리 및 안정성 수준을 설명하는 README를 추가하십시오.

      이 크레이트는 rustc 내부에서 사용하기 위해 Rust 컴파일러 팀이 개발하고 유지 관리하며, 특히 .template 작업 영역이 이를 담당합니다. 이 크레이트는 호환성을 깨는 변경이 정기적으로 발생하며 안정성을 보장하지 않습니다 | stable 상태를 유지하고 호환성을 깨는 변경을 최소화하는 것을 목표로 합니다.

   3. rust-lang/rust에 있는 LICENSE-APACHE 및 LICENSE-MIT 라이선스 파일을 포함하십시오.

   4. rust-lang/rust의 CODE_OF_CONDUCT 파일을 포함하거나 링크하십시오.

   5. 적절한 .gitignore를 생성하십시오(합리적인 기본값은 여기에 있습니다).

   6. P-high, P-medium, P-low, I-compiler-nominated 및 T-compiler 레이블을 생성하십시오.

4. rustc와 통합하기 전에 필요한 초기 개발을 수행하십시오.
5. 시맨틱 버저닝에 따라 초기 버전을 게시하십시오.
6. 적절한 트리 내부 크레이트에 해당 크레이트를 의존성으로 추가하고 사용을 시작하십시오.

서드파티 크레이트

컴파일러에서 기존 서드파티 크레이트의 기능을 사용하는 것이 바람직할 때가 있습니다.

서드파티 크레이트는 언제 컴파일러 의존성으로 추가할 수 있습니까?

컴파일러에 포함되는 서드파티 크레이트는 잘 유지 관리되고 있어야 하며, 가능하다면 컴파일러 팀 구성원이 메인테이너로 추가되는 것이 바람직합니다. 이 결정을 내리기 전에 컴파일러 팀의 다른 구성원들과 상의해야 합니다.

트리 외부 크레이트의 서드파티 의존성은 어떻습니까?

컴파일러에서 사용되며 compiler-team이 유지 관리하는 모든 크레이트에도 동일한 정책이 적용됩니다.

트리 외부 크레이트 목록

이 섹션에는 컴파일러 팀이 유지 관리하는 기존 트리 외부 크레이트 목록이 있습니다:

• rust-lang/chalk
• rust-lang/polonius
• rust-lang/measureme
• rust-lang/thorin