서드파티 및 아웃오브트리 크레이트 정책

이 정책은 컴파일러에서 사용할 아웃오브트리 크레이트를 만들고 컴파일러 내에서 서드파티 크레이트를 사용하는 것에 대한 가이드라인을 설명합니다.

아웃오브트리 크레이트

이 정책의 주요 목표 중 하나는 컴파일러에서 사용되는 아웃오브트리 크레이트(적어도 컴파일러 팀이 관리하며 rust-lang에 있는 것들)를 구성하는 방식에 일관성이 있도록 하고, rust-lang/rust와 이러한 크레이트 전반에 걸쳐 경험이 균일하도록 하는 것입니다.

컴파일러의 일부는 언제 아웃오브트리 크레이트로 분리해야 합니까?

이는 컴파일러 팀 구성원의 재량에 맡겨져 있지만, 주간 트리아지 회의에서 문제를 제기하거나 승인 결정을 통해 비동기적으로 나머지 팀과 논의해야 합니다. 크레이트가 워킹 그룹의 산물인 경우, 아웃오브트리 크레이트가 적합하다는 합의가 워킹 그룹 내에 이미 있어야 합니다.

아웃오브트리 크레이트를 만드는 것을 고려할 때, 크레이트가 얼마나 범용적이어야 하는지와 널리 사용될 경우 이로 인해 늘어날 유지보수 부담 사이의 균형을 고려할 가치가 있습니다.

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

아웃오브트리 컴파일러 크레이트는 rust-lang 조직에서 호스팅되어야 합니다 - 이는 외부 인프라 도구와의 통합을 단순화하며 GitHub에서 기존 팀 권한을 물려받게 됩니다. 어떤 문서에서든 컴파일러 팀과 적절한 워킹 그룹이 해당 크레이트에 대한 책임이 있다는 점이 명확히 드러나야 합니다. 다른 조직이나 개인 저장소에서 프로토타입으로 시작하는 것은 권장되지 않습니다.

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

예, 이는 권장됩니다. 이를 위해서는 팀과 논의하고 저장소 이전에 대한 GitHub 문서를 숙지한 다음 이전을 수행하도록 준비하십시오. 이전이 완료되면 원래 계정이나 조직에 리다이렉트가 남게 되며, 이는 이전된 저장소의 새로운 포크 이름과 충돌하게 됩니다 - 이를 해결하려면 GitHub에 이메일을 보내야 합니다.

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

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

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

이 크레이트들은 어떤 이름을 붙여야 합니까?

크레이트 이름은 새로운 아웃오브트리 크레이트가 컴파일러 팀에 제안될 때 논의됩니다.

크레이트 이름은 경우에 따라 다르게 정해집니다. 본질적으로 컴파일러와 연결된 크레이트는 rustc_ 접두사가 붙은 이름을 사용하는 것이 유리합니다. 이는 잠재적 사용자에게 해당 크레이트가 얼마나 stable할지를 나타내는 지표입니다. 좀 더 범용적인 다른 크레이트들은 컴파일러와 분리된 이름을 갖게 됩니다.

아웃오브트리 크레이트에 대한 검토 정책에 제한이 있습니까?

일반적으로 워킹 그룹과 팀 구성원들은 자신들의 그룹에 가장 적합한 방식을 사용하여 크레이트를 자유롭게 유지보수할 수 있지만, 컴파일러와 아웃오브트리 크레이트 전반에 어느 정도의 통일성이 있도록 몇 가지 제한이 있습니다:

• rust-lang/rust에서 r+ 권한을 가진 모든 사람은 PR을 검토하고 승인할 수 있어야 합니다.
• 가능한 경우, 크레이트(또는 관련 워킹 그룹)의 활발한 참여자만이 해당 크레이트의 검토 순환에 있으면 됩니다.
• 해당 리뷰어가 워킹 그룹이나 크레이트 유지 관리에 적극적으로 참여하고 있다면, Rust 전체에 대한 r+ 권한이 없는 추가 리뷰어를 크레이트에 두어도 무방합니다.
• 주요 풀 리퀘스트에는 여러 명의 검토자가 있어야 합니다.

out-of-tree 크레이트에는 무엇이 요구됩니까?

out-of-tree 크레이트는 다음을 반드시 준수해야 합니다:

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

out-of-tree 크레이트에 커뮤니티 인프라가 요구됩니까?

트리 외부 크레이트를 위해 커뮤니티 인프라(예: Zulip 서버/스트림)를 만들어야 한다는 요구 사항은 없습니다. out-of-tree 크레이트가 대규모 기여자·사용자 커뮤니티를 형성하게 되면 이것이 바람직할 수 있으나, 그렇지 않은 경우 처음에는 워킹 그룹이나 컴파일러 팀 스트림을 사용해야 합니다.

주 Rust Zulip 서버에서 이슈와 PR에 자동 링크되는 링크화 기능은 요청 시 추가할 수 있습니다.

out-of-tree 크레이트 작업에 관한 안내가 있습니까?

rustc-dev-guide의 Using external repositories를 참고하십시오.

out-of-tree 크레이트에서 안정화/시맨틱 변경 사항은 어떻게 처리해야 합니까?

언어에 대한 안정화 또는 시맨틱 변경을 초래하는 out-of-tree 크레이트의 모든 변경 사항에는 언어 팀을 참여시키는 것이 중요합니다. rust-lang/rust에 대한 PR에서 서브모듈 변경 사항은 마치 그 변경이 rust-lang/rust에 직접 구현된 것처럼 적절히 레이블(예: relnotes, t-compiler, t-lang)을 붙여야 하며, 컴파일러나 해당 트리 외부 크레이트에 익숙하지 않은 사람에게 명확하지 않은 경우 변경 사항에 대한 설명을 포함해야 합니다.

out-of-tree 크레이트에서 릴리스는 언제 이루어져야 합니까?

트리 외부 저장소에서 패치를 병합할 권한을 가진 팀 구성원은 누구든 적절하다고 판단될 때 새 릴리스를 낼 풀 리퀘스트를 생성할 수 있으며, 다른 모든 풀 리퀘스트와 마찬가지로 다른 팀 구성원의 검토를 받아야 합니다. 새 릴리스는 테스트를 통과하고 새 릴리스를 정당화할 만한 변경 사항(예: 의존성 업그레이드, 새 기능, 버그 수정 등)이 있는 버전의 크레이트여야 합니다.

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

요약하면, out-of-tree 크레이트를 설립하는 절차는 다음과 같습니다:

1. 적절한 경우, out-of-tree 크레이트의 필요성을 워킹 그룹 내에서 논의하고 확인하십시오.
2. 이 문서를 수정하여 아래 목록에 크레이트를 추가하는 PR을 생성하십시오. @rfcbot merge를 사용하여 컴파일러 팀 구성원들의 동의를 얻으십시오.
3. 팀 저장소를 사용하여 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. 해당 크레이트를 인트리 크레이트의 의존성으로 추가하고 사용을 시작하십시오.

서드파티 크레이트

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

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

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

아웃오브트리 크레이트에 대한 서드파티 의존성은 어떻습니까?

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

아웃오브트리 크레이트 목록

이 절에는 기존의 아웃오브트리, 컴파일러 팀 유지 관리 크레이트 목록이 포함되어 있습니다:

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