PR 생명 주기

리뷰 전

PR 열기

이제 풀 리퀘스트(PR)를 제출할 준비가 되셨습니까? 좋습니다! 알아 두어야 할 몇 가지 사항은 다음과 같습니다.

다른 브랜치를 대상으로 해야 한다고 확실히 알고 있는 경우가 아니라면, 모든 풀 리퀘스트는 main 브랜치를 대상으로 제출해야 합니다.

PR을 제출하기 전에 몇 가지 스타일 검사를 실행하십시오:

./x test tidy --bless

모든 풀 리퀘스트 전에(그리고 풀 리퀘스트의 모든 새 커밋 전에) 이 검사를 수행할 것을 권장합니다. 이 검사를 잊지 않도록 매 푸시 전에 실행되는 git 훅을 추가할 수 있습니다. CI도 tidy를 실행하며, tidy가 실패하면 CI도 실패합니다.

PR 설명

GitHub에서는 키워드를 사용하여 이슈를 닫을 수 있습니다. 이슈 트래커를 깔끔하게 유지하려면 이 기능을 사용해야 합니다. 다만 일반적으로 “closes #123” 문구는 커밋 메시지보다 PR 설명에 넣는 것이 좋습니다. 특히 리베이스 중에 커밋에서 이슈 번호를 언급하면 해당 이슈에 “스팸“이 쌓일 수 있습니다.

하지만 PR이 stable-to-beta 또는 stable-to-stable 회귀를 수정하며 베타 및/또는 stable 백포트가 승인된 경우(즉, beta-accepted 및/또는 stable-accepted로 표시된 경우), 수정 사항이 main에 반영될 때 해당 이슈가 자동으로 닫히지 않도록 그러한 키워드를 사용하지 마십시오. PR 설명을 수정하되 이슈는 어딘가에 계속 언급해 두십시오. 예를 들어 Fixes (after beta backport) #NNN.처럼 쓸 수 있습니다.

CI

풀 리퀘스트는 사람이 리뷰할 뿐만 아니라 지속적 통합(CI) 덕분에 자동으로 테스트도 됩니다. 기본적으로 풀 리퀘스트를 열거나 업데이트할 때마다 CI가 컴파일러를 빌드하고 컴파일러 테스트 스위트로 테스트하며, 풀 리퀘스트가 Rust의 스타일 가이드라인을 준수하는지 확인하는 등의 다른 테스트도 수행합니다.

지속적 통합 테스트를 실행하면 PR 작성자는 첫 번째 리뷰 주기를 거치지 않고도 실수를 일찍 발견할 수 있고, 리뷰어는 특정 풀 리퀘스트의 상태를 계속 파악할 수 있습니다.

Rust에는 CI 용량이 충분하므로, 변경 사항을 푸시할 때마다 컴퓨팅 자원을 낭비하는 것은 아닌지 걱정할 필요가 전혀 없습니다. 생산성에 도움이 된다면 CI를 사용하여 변경 사항을 테스트하는 것도 전혀 문제없습니다(오히려 권장합니다!). 특히 전체 ./x test 스위트는 실행하는 데 매우 오랜 시간이 걸리므로 로컬에서 실행하는 것을 권장하지 않습니다. Rust의 CI를 사용하여 변경 사항을 테스트하는 방법은 CI로 테스트하기 장을 참고하십시오.

PR 리뷰

r?

PR에는 리뷰어가 자동으로 배정됩니다. r? @username을 사용하여 리뷰어를 바꿀 수 있습니다. 자세한 내용은 PR 할당을 참고하십시오.

리베이스

Rust는 병합 커밋 금지 정책을 따릅니다. 따라서 병합 충돌이 발생하면 병합 대신 항상 리베이스를 해야 합니다. 예를 들어 main 브랜치의 최신 변경 사항을 기능 브랜치로 가져올 때는 항상 리베이스를 사용하십시오. PR에 병합 커밋이 포함되어 있으면 has-merge-commits로 표시됩니다. 대화형 리베이스 등으로 병합 커밋을 제거한 후에는 해당 레이블을 다시 제거해야 합니다:

@rustbot label -has-merge-commits

자세한 내용은 이 장을 참조하십시오.

병합 충돌이 발생하거나 리뷰어가 변경을 요청하면 PR은 S-waiting-on-author로 표시됩니다. 이를 해결한 후에는 @rustbot을 사용하여 PR을 S-waiting-on-review로 표시해야 합니다:

@rustbot ready

브랜치를 최신 상태로 유지하기

rust-lang/rust의 CI는 브랜치의 기반 커밋이 아니라 현재 main에 패치를 직접 적용합니다. 따라서 브랜치가 오래되었다면 명시적인 병합 충돌이 없더라도 예기치 않은 실패가 발생할 수 있습니다.

브랜치는 필요할 때만 업데이트하십시오. 병합 충돌이 있을 때, 업스트림 CI가 망가져 통과한 PR을 막고 있을 때, 또는 메인테이너가 요청할 때가 이에 해당합니다. 리뷰 중이며 이미 통과한 PR은 꼭 필요한 경우가 아니면 업데이트하지 마십시오. 리뷰 중에는 피드백을 반영하는 커밋을 점진적으로 추가하십시오. 스쿼시나 리베이스는 마지막에 하거나 리뷰어가 요청할 때만 하는 것이 좋습니다.

업데이트할 때는 git push --force-with-lease를 사용하고, 무엇이 바뀌었는지 설명하는 간단한 댓글을 남기십시오. 일부 저장소는 리베이스 대신 upstream/main에서 병합하는 방식을 선호하므로 해당 프로젝트의 관례를 따르십시오. 자세한 방법은 최신 상태 유지하기를 참조하십시오.

리베이스한 후에는 CI가 실행되기 전에 문제를 발견할 수 있도록 관련 테스트를 로컬에서 실행하는 것이 좋습니다.

리뷰 기다리기

참고

풀 리퀘스트 리뷰어는 대개 업무량이 한계에 이른 상태이며, 그중 상당수는 자원봉사로 기여하고 있습니다. 리뷰 지연을 최소화하려면 풀 리퀘스트 작성자와 담당 리뷰어는 적절한 시점에 다음 명령을 사용하여 리뷰 레이블(S-waiting-on-review 및 S-waiting-on-author)이 항상 최신 상태로 유지되도록 해야 합니다:

@rustbot author: 리뷰가 끝났으므로 PR 작성자가 댓글을 확인하고 그에 따라 조치해야 합니다.

@rustbot ready: 작성자가 리뷰받을 준비가 되었으며, 이 PR이 리뷰어의 대기열에 다시 추가됩니다.

리뷰어도 사람이며, 대부분 여가 시간에 rustc 작업을 한다는 점을 유념하십시오. 따라서 리뷰어가 응답하고 PR을 리뷰하는 데 시간이 걸릴 수 있습니다. 또한 리뷰어가 자신에게 할당된 PR 중 일부를 놓칠 수도 있습니다.

PR 진행을 돕기 위해 Triage WG는 리뷰를 기다리면서 최소 2주 동안 논의가 없었던 모든 PR을 정기적으로 검토합니다. 2주 안에 리뷰를 받지 못하면 Zulip(#t-release/triage)에서 Triage WG에 편하게 문의하십시오. Triage WG는 언제 핑을 보내야 하는지, 누가 휴가 중일 수 있는지 등을 알고 있습니다.

리뷰어는 GitHub 코드 리뷰 인터페이스를 사용하여 몇 가지 변경을 요청할 수 있습니다. 또한 일부 PR에 대해서는 특별한 절차를 요청할 수도 있습니다. 이러한 절차의 몇 가지 예시는 Crater 및 호환성을 깨는 변경 장을 참고하십시오.

이해되지 않거나 동의하지 않는 부분이 있다면 자유롭게 질문하거나 논의하십시오. 다만 Rust 팀의 누군가가 승인하지 않는 한 PR은 병합되지 않는다는 점을 인지하십시오. 리뷰어가 r=me after fixing ...와 같은 코멘트를 남겼다면, 이는 리뷰어가 PR을 승인했다는 뜻이며, 사소한 문제를 수정한 후 @bors r=reviewer-github-id(예: @bors r=eddyb) 코멘트를 달아 병합할 수 있습니다. r=someone에는 권한이 필요하며, r=someone을 코멘트로 달았을 때 bors가 “🔑 Insufficient privileges…“와 같은 메시지를 남길 수 있다는 점에 유의하십시오. 그런 경우에는 리뷰어에게 PR을 다시 확인해 달라고 요청해야 합니다.

리뷰 과정에서 일부 PR에는 다음과 같은 몇 가지 일이 일어날 수 있습니다

변경 사항이 충분히 큰 경우, 리뷰어는 해당 PR에 대해 FCP를 요청할 수 있습니다. 이를 통해 관련 팀의 모든 구성원이 변경 사항을 검토할 기회를 갖게 됩니다.
변경 사항이 기존 코드를 깨뜨릴 수 있는 경우, 리뷰어는 crater 실행을 요청할 수 있습니다. 이는 여러분의 변경 사항을 반영하여 컴파일러를 빌드한 후, 수정된 컴파일러로 crates.io의 모든 크레이트를 컴파일해 보는 작업입니다. 이는 여러분이 생태계의 상당 부분에 영향을 미치는 컴파일러 동작 변경을 도입했는지 확인하는 훌륭한 스모크 테스트입니다.
PR의 diff가 크거나 리뷰어가 바쁜 경우, 먼저 병합된 다른 PR과 여러분의 PR 사이에 병합 충돌이 발생할 수 있습니다. 이러한 병합 충돌은 일반적인 git 절차에 따라 해결하십시오.

r+

누군가 여러분의 풀 리퀘스트를 리뷰하고 나면, 풀 리퀘스트에 r+라는 표시를 남깁니다. 다음과 같은 형태입니다:

@bors r+

이는 우리의 사랑스러운 통합 봇인 @bors에게 여러분의 풀 리퀘스트가 승인되었음을 알립니다. 그러면 PR은 병합 대기열에 들어가며, 그곳에서 @bors가 우리가 지원하는 모든 플랫폼에서 모든 테스트를 실행합니다.

변경의 규모에 따라 약간 다른 형태의 r+를 보게 될 수도 있습니다:

@bors r+ rollup

추가된 rollup은 @bors에게 이 변경 사항이 항상 “롤업“되어야 함을 알립니다. 롤업된 변경 사항은 과정을 빠르게 진행하기 위해 다른 PR과 함께 테스트되고 병합됩니다. 일반적으로 서로 충돌하지 않을 것으로 예상되는 작은 변경 사항만 “항상 롤업“으로 표시됩니다.

인내심을 가지십시오. 이 과정은 시간이 걸릴 수 있으며 대기열이 길어지는 경우도 있습니다. 또한 PR은 절대 수동으로 병합되지 않는다는 점에 유의하십시오.

모든 것이 잘 진행되면 @bors가 여러분의 코드를 main에 병합하고 풀 리퀘스트를 닫습니다. 여러분의 코드는 다음 nightly 컴파일러에 포함됩니다 :)

Rust 컴파일러 개발 가이드