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

검토 정책

이 문서는 Rust 컴파일러에 대한 기여물에 관한 저희의 리뷰 정책을 설명합니다. 이 문서의 대상 독자는 기여자와 검토자 모두입니다.

이 정책의 목적은 Rust 프로젝트의 기대치를 명확히 함으로써 기여자가 더 리뷰하기 쉬운 풀 리퀘스트를 만들도록 돕고, 리뷰어에게도 확인해야 할 공통 사항의 편리한 목록을 제공하는 것입니다. 양측이 함께 작업하는 방식을 명확히 이해하면 프로젝트에 도움이 될 것입니다.

코드 검토의 목적은 다음과 같습니다.

  • 버그와 사용성 및 성능 회귀가 도입될 위험을 줄이는 것입니다.
  • 저희 코드를 유지보수 가능하게, 즉 읽기 쉽고, 문서화되어 있으며, 잘 테스트된 상태로 유지하는 것입니다.
  • 변경 사항이 큰 그림과 적절한 맥락을 염두에 두고 이루어지도록 보장하는 것입니다. 이는 개별적으로는 무해해 보이지만 더 큰 맥락에서는 문제가 있거나 바람직하지 않은 변경 사항에 특히 중요합니다.

검토는 제안된 변경 사항을 다른 관점에서 바라볼 또 다른 시각을 도입함으로써 이를 달성하며, 이는 실수를 조기에 발견하고 변경 사항 이면의 추론에 존재하는 잠재적 사각지대를 찾아낼 가능성을 높여줍니다.

기본 검토 요구사항

검토가 효과적이려면 충족되어야 할 몇 가지 요구사항이 있습니다.

  • 검토자는 검토 대상 코드에 대해 충분한 이해를 갖추고 있어야 합니다.
    • 이는 주어진 변경 사항의 명백하지 않고 의도하지 않은 부작용을 발견하는 데 중요합니다.
  • 풀 리퀘스트 작성자는 다음을 제공해야 합니다.
    1. 오타 수정과 같이 매우 사소한 변경이 아닌 이상, 변경 사항에 대한 간결하고 상위 수준의 설명과 그 뒤에 있는 (2) 근거입니다.
    2. 근거가 더욱 유용하도록, 작성자는 잠재적인 쟁점, 이루어져야 했던 타협, 고려된 대안적 접근 방식, 관련 문서·논의·맥락 등을 나열하는 것이 권장됩니다.
    • 코드 검토는 어려운 작업이며, 검토자에게는 이를 수행할 시간이 한정되어 있습니다. 리뷰어가 풀 리퀘스트의 의도와 맥락을 스스로 조합해내지 않도록 리뷰 과정을 순조롭게 시작하게 하면, 속도가 빨라질 뿐만 아니라 리뷰의 품질도 향상됩니다.
  • 검토자는 자신이 해당 변경 사항을 승인할 적임자인지에 대해 명확한 판단을 갖고 있어야 합니다.
    • 검토 대상 코드에 대한 지식은 이 질문에 답하는 데 명백하지만 유일한 기준은 아닙니다.
    • 절차상으로 리뷰어는 다음 사항도 결정해야 합니다.
      • 리뷰어가 단독으로 결정을 내릴 수 있습니까?
      • 해당 풀 리퀘스트가 승인 절차를 거쳐야 하는가?
      • 해당 풀 리퀘스트가 다른 팀, 특히 t-lang의 검토 및/또는 승인을 필요로 하는가?
      • 이 변경이 stable 코드를 망가뜨리거나, 저희가 의도하지 않은 새 코드를 받아들이기 시작할 수 있습니까? 풀 리퀘스트에 위험 요소가 포함되어 있다면, 그것이 충분히 정당화되는가? 이 변경이 crater 실행을 통한 생태계 영향 평가를 필요로 합니까?
      • 해당 풀 리퀘스트가 상당한 성능 변화를 가져올 것인가? 성능 회귀가 발생할 가능성이 있다면, 그것이 정당화됩니까? 해당 풀 리퀘스트가 성능 실행을 필요로 하는가?
      • 리뷰어가 충분히 철저하고 시기적절하게 리뷰를 수행할 수 있습니까?
      • 리뷰어가 충분히 편향되지 않은 관점을 제공할 만큼 공정합니까? 예를 들어 공동 저작(리뷰어가 PR에 충분히 유의미한 변경을 가한 경우) 또는 기타 이해 상충 때문에 그렇지 않을 수 있습니까?

리뷰 체크리스트

다음 질문 목록은 리뷰어와 PR 작성자 모두가 PR을 좋은 형태로 만들고 위의 기준을 충족하도록 돕습니다:

PR 작성자 및 리뷰어를 위한 체크리스트

  • PR 메시지에 다음이 포함되어 있습니까?
    • ..변경 사항에 대한 간결한 상위 수준 설명? (무엇이 변경되는지)
    • ..그렇게 하는 이유에 대한 명확한 근거? (왜 변경되는지)
    • ..사소하지 않고 적절한 경우, 버그가 어떻게 수정되었는지 또는 변경 사항이 어떻게 구현되었는지?
    • ..잠재적인 쟁점들의 목록? 대안? 트레이드오프? 위험?
    • ..관련 이슈, RFC, MCP 등에 대한 링크?
  • 이 PR은 회귀 테스트가 필요합니까? 이 변경 사항이 **주요 변경 제안(MCP)**으로 다뤄져야 합니까? 이미 다뤄지고 있습니까? 이미 열려 있는 MCP가 있다면 이미 승인되었습니까, 아니면 PR이 그것에 막혀 있습니까?
  • 이 변경은 **주요 변경 제안(MCP)**의 대상이어야 합니까? 이미 다뤄지고 있습니까? 이미 열려 있는 MCP가 있다면, 그것이 이미 승인되었습니까, 아니면 PR이 그것에 막혀 있습니까?
  • PR에 성능 실행이 필요합니까?
  • PR에 다른 팀의 리뷰 및/또는 승인이 필요합니까?
    • 예를 들어, 생태계 영향이 크거나 언어 변경이 있는 린트 확장의 경우 t-lang
  • PR이 사소하지 않은 방식으로 다른 팀에 영향을 미칩니까? 영향을 받는 팀에게 미리 알려야 합니까?
    • 예: rustfmt나 rust-analyzer, 또는 서브트리에 대한 변경.
  • 1년 후에 이 PR을 이해하려는 사람이 무슨 일이 일어나고 있는지 빠르게 재구성할 수 있겠습니까?
  • 새 코드가 적절히 문서화되어 있습니까? 기존 문서가 여전히 최신 상태입니까?
  • PR의 변경 사항에 Reference나 에디션 가이드의 업데이트가 필요합니까?
  • 이 PR은 다음 중 어떤 회귀를 초래합니까?
    • 오류 메시지 품질
    • 유지보수성(예: 복잡한 코드, 문서 부재, unsafe)
    • 특정 대상 플랫폼
    • 다운스트림 도구(예: 링커, 디버거)
    • 컴파일 시간
    • 메모리 사용량
    • 타겟(예: 베이스라인, 타겟 기능, 호출 규약 등)

리뷰어를 위한 체크리스트

  • 제가 이 PR을 검토하기에 적합한 사람입니까:
    • 이 PR의 변경 사항은 t-compiler의 관할에 속합니까?
    • 코드를 충분히 이해하고 있습니까?
    • 명백하지 않은 부작용을 발견할 수 있습니까?
    • 이 PR로 인해 발생한 버그를 고칠 수 있습니까?
    • 적절한 시간 내에 리뷰를 수행할 수 있습니까?
    • 어떤 이유로든 PR을 빨리 승인해야 한다는 압박감을 느끼고 있습니까?
    • 충분히 공정합니까?
  • 병합 전에:
    • PR 제목과 설명이 여전히 정확합니까?
    • 커밋 이력이 충분히 깔끔합니까? PR 이력에 “오타 수정” 커밋이 16개나 있을 필요는 없습니다.
    • 이 PR이 관련 이슈를 올바르게(또는 올바르지 않게) 닫습니까?
  • 다른 관련 팀에서 리뷰어를 굴려야 합니까?

일반적인 상황을 다루기 위한 안내

대부분의 경우 이 정책을 어떻게 적용할지 결정하는 데는 상식만으로 충분합니다. 하지만 때로는 어떻게 진행해야 할지 즉시 명확하지 않은 회색 지대가 존재합니다. 이 섹션에서는 몇 가지 흔한 사례와 그것들을 다루는 방법에 대한 안내를 함께 나열합니다.

저는 리뷰하기에 적합한 사람이 아닌 것 같습니다 - 이제 어떻게 해야 합니까?

(rustbot 등을 통해) PR이 무작위로 배정되었지만 리뷰하기가 편하지 않다고 느끼는 것은 지극히 정상적인 일입니다. 구체적인 사례에 따라 할 수 있는 일은 다음과 같습니다:

  • 변경 사항이 정말로 크거나 논쟁의 여지가 있어 보인다면, 작성자에게 적절한 승인 절차를 거치도록 권하는 것을 고려하십시오.
  • 리뷰에 딱 맞는 사람을 알고 있다면, r? @<github-name>을 통해 그들을 배정하십시오. 그들이 맡을 수 있는지 묻는 댓글을 남기는 것이 예의 바르지만 – 사전에 그들이 실제로 할 수 있는지 확인할 필요는 없습니다.
  • 변경이 그리 복잡하지 않고, 무작위로 배정된 다른 컴파일러 리뷰어 역시 이 PR에서 어려움을 겪지 않을 것으로 예상된다면, r? compiler로 무작위 컴파일러 리뷰어를 다시 뽑을 수 있습니다.
  • 변경이 복잡하거나, 다른 컴파일러 리뷰어를 무작위로 다시 뽑아도 여러 번 재추첨으로 이어질 것으로 예상된다면, #t-compiler/private에 스레드를 열어 팀의 나머지 구성원에게 — 리뷰할 수 있는 사람이 있는지, 혹은 팀이 이 변경을 아예 받아들이는 데 편안함을 느끼는지 물어봐야 합니다.
  • 변경이 다른 팀을 대상으로 한다면, 해당 팀에서 리뷰어를 뽑으십시오(예: r? compiler).

리뷰어를 찾는 데 도움이 필요하면 언제든지 #t-compiler Zulip 스트림에서 도움을 요청할 수도 있습니다. 편안하게 느끼는 범위 내에서, PR을 최종 리뷰어에게 넘기기 전에 초기 리뷰를 수행하는 것을 권장합니다. 이렇게 하면 PR 작성자가 더 빨리 유용한 피드백을 받을 수 있고, 이후 리뷰어들의 작업량이 줄어들며, 여러분 자신도 컴파일러의 다양한 영역에 대한 이해를 높일 수 있습니다.

기여가 승인 결정을 필요로 하는지 불분명한 경우

어떤 기여가 더 넓은 팀 차원의 승인을 필요로 할 수 있다고 생각되면, 제안, 승인 및 안정화 문서를 확인하십시오. 해당 기여가 그 문서의 예시 중 어느 것에도 해당하지 않는다면, #t-compiler/private에 스레드를 열어 질문하십시오.

논의나 근거가 지나치게 불투명한 경우

때때로 설명이나 근거 없이 사전 논의의 결과처럼 보이는 PR들이 있습니다. 이런 PR들은 보통 “Change X“와 같은 제목을 가지고 있으며, PR 메시지의 유일한 내용은 “r? @xyz“입니다. 변경이 타당해 보이고 심지어 컴파일러 팀 구성원이 제안한 것일 수도 있지만, 이는 좋은 형식이 아닙니다.

기여자들이 몇 년 후 비섹션 작업 중에 해당 PR을 우연히 발견했을 때, 오프라인이나 다른 곳에서 논의된 맥락이 전혀 없이 PR만 남아 있고, 그 정보를 이후 기여자들이 알 수 없게 될 수 있습니다. 이는 유지보수성에 좋지 않습니다. 관련 맥락을 포함시키는 것은 미래의 PR 작성자 본인에게도 매우 자주 도움이 됩니다!

PR 메시지는 무엇이 변경되고 있는지, 왜 변경되고 있는지, 그리고 그 밖에 관심을 가질 만한 사항에 대해 그 자체로 완결된 설명을 제공해야 합니다.

몇 년 후 PR이 건드린 코드와 관련된 버그를 수정해야 하고 그렇게 되어 있는 이유를 재구성해야 하는 사람의 입장이 되어 보십시오.

리뷰어와 PR 작성자가 같은 조직에 속해 있거나 같은 고용주 밑에서 일하는 경우

같은 회사의 두 직원이 서로의 PR을 리뷰하는 것을 막는 규칙은 없습니다. 우리는 컴파일러 팀 리뷰어들이 선의로 행동한다고 가정하며, 팀 구성원들에게 그렇게 할 것이라는 신뢰를 부여합니다.

이러한 경우의 우려 사항은 다른 어떤 두 리뷰어의 경우와도 다르지 않습니다. 우리는 위에서 밝힌 메커니즘과 원칙이 고용주가 누구든 간에 모든 리뷰어에게 존중되기를 기대합니다. PR이 이루어지고 있는 변경 사항을 간결하게 설명하고 있습니까? 이후의 기여자들이 그 추론을 따라가고 무슨 일이 일어나고 있는지 재구성할 수 있도록, 그 변경이 타당한 이유에 대해 명확하고 투명한 근거를 제공하고 있습니까? 쟁점이 되는 부분들이 논의되고 정리되었습니까? 그렇다면 문제없습니다.

무언가가 논쟁의 여지가 있는지 확신이 서지 않는다면, @rust-lang/compiler에 알리고 다른 의견을 구하십시오. 어떤 기여가 더 넓은 팀 차원의 승인을 필요로 할 수 있다고 생각되면, 제안, 승인 및 안정화 문서를 확인하십시오.

리뷰와 멘토링

PR을 통해 누군가를 멘토링하는 과정에서, 리뷰어가 결과적으로 변경 사항을 사실상 공동 작성하게 되는 일이 종종 발생합니다. 이는 리뷰어가 사실상 자신의 변경 사항을 승인하는 셈이 되므로 까다로운 경우일 수 있습니다. 어떻게 진행할지 결정할 때 고려해야 할 사항이 여러 가지 있습니다:

  • 변경 사항의 전반적인 방향이 이미 승인 결정의 일환으로 승인되었고, 멘토링 과정에서 제공된 구체적인 조언이 사소한 기술적 문제를 해결하는 것에만 관련되어 있었다면, 추가 리뷰는 필요하지 않습니다.
  • 마찬가지로, 논쟁의 여지가 있는 결정이 PR상에서 다른 컴파일러 팀 구성원들과 눈에 띄게 논의되고 해결되었으며, 나머지 변경 사항이 합의된 전반적인 방향에서 벗어나지 않는다면 이 경우에도 추가 리뷰는 필요하지 않습니다.
  • PR이 리뷰어의 구체적인 제안에 대한 응답으로 열렸고(그리고 그 변경이 전혀 사소하지 않은 경우), 최종 리뷰는 다른 사람이 수행하는 것이 바람직합니다. 다만 최초 리뷰어/멘토는 PR을 넘기기 전에 그것을 좋은 상태로 만드는 데 도움을 주도록 권장됩니다.

일반적으로 이런 경우에는 해당 분야에 지식이 있는 사람에게 두 번째 의견을 구하는 것이 바람직하며, 이는 멘토가 놓칠 수 있는 간과나 사각지대를 발견할 가능성을 높이기 위함입니다.

변경되는 코드를 아무도 이해하지 못하는 경우

때로는 더 이상 아무도 이해하지 못하는 코드에 버그가 있는 경우가 있습니다. 원저자는 연락이 닿지 않으며, 제안된 수정의 영향을 가늠하기 어렵습니다. 이런 경우 리뷰어는 (자신이 주 리뷰어로 계속 남고자 한다면) PR에 I-compiler-nominated를 붙이거나, 이슈에 컴파일러 팀 리드를 배정하고 S-waiting-on-team 레이블을 추가하는 것이 좋은 방법입니다.

두 경우 모두, 해당 PR은 주간 트리아지 회의에 상정됩니다. 또한 수정 중인 문제에 대한 설명, 불명확한 부분, 잠재적 위험, 고려된 대안 등 해당 이슈에 대해 가능한 한 많은 정보를 수집하고 문서화하는 것이 특히 가치 있습니다. 또한 해당 영역에 대한 이해 부족을 문서화하기 위해 추적 이슈를 여는 것도 좋은 방법이며, 구체적인 질문과 우려 사항, 버그를 문서화해 두면 이후 컴파일러 팀 구성원들이 더 나은 이해를 회복했을 때 해결할 수 있습니다.

리뷰어는 PR 작성자에게 이런 종류의 정보를 코드 내 주석이나 PR 메시지(이는 git 커밋 이력의 일부가 됩니다)에 추가하도록 요청해야 합니다.

PR이 외부 프로젝트에서 rustc 내부 요소를 사용할 수 있도록 지원하는 변경을 가하는 경우

이는 사안별로 판단해야 합니다.

일반적으로, 컴파일러 영역의 소유자가 동의하는 한(따라서 그들에게 할당하기만 하면 됩니다), 무언가를 공개하거나 정리하거나 더 일반화하는 변경은 허용해야 합니다.

구체적인 예를 들면, 누군가 MIR 인터프리터를 사용 중이고 무언가를 공개하고 싶어하는 경우, 이는 대체로 문제가 되지 않지만, 일부 함수는 MIR 인터프리터 내의 불변 조건을 유지하기 위해 의도적으로 모듈 또는 크레이트 전용으로 설정되어 있습니다. 그러니 기본적으로 그러한 PR은 관련된 사람들에게 배정하기만 하면 됩니다(대개 이들은 이 부분의 변경에 대해 핑을 받고 싶다고 rustbot에 알려두었기 때문에 어차피 핑을 받게 됩니다).

이러한 API에는 어떤 외부 소비자가 해당 API와 관련이 있는지, 그리고 어떤 목적을 위한 것인지 명시하는 문서 주석을 요구하십시오.

어떤 기여가 더 넓은 범위의 팀 승인을 필요로 할 수 있다고 생각된다면, 제안, 승인, 안정화 문서를 확인하십시오.

이는 겉보기와 달리, 내부용으로 여겨지던 컴파일러 API를 외부 소비자에게 종속시킬 수 있다는 점에 유의하십시오. (rust-lang/ 프로젝트가 아닌) 외부 소비자에게는, 이것이 컴파일러에 상당한 유지보수 부담을 주지 않는 한(예: 리팩터링에 방해가 되지 않는 한) 편의를 제공할 수 있지만, 엄격한 안정성 보장은 약속되지 않는다는 점을 전달하십시오.

PR이 매우 크고 복잡한 경우

리뷰어가 매우 크고 복잡한 PR을 무조건 감내해야 하는 것은 아닙니다. 기여자는 리뷰가 가능하도록 자신의 작업을 분할할 것이 기대되며, 예를 들어 개별적으로 논리적으로 더 자기완결적인, 더 소화하기 쉬운 일련의 PR로 나누는 것이 그 예입니다. 일반적으로 큰 영향을 미치는 변경을 제출하기 전에, 기여자는 관련 팀과 미리 설계에 대해 논의했어야 하며, 따라서 그러한 논의를 참조하는 것은 기여자의 의무입니다.

확신이 서지 않을 때는 PR을 팀의 관심에 맡기고(zulip 스레드를 통하거나, 컴파일러 트리아지 회의에 지명하는 방식으로), 팀이 다음을 결정할 수 있습니다:

  • 팀은 PR 작성자가 큰 변경 사항을 개별적으로도, 그리고 더 큰 변경의 맥락에서도 리뷰 가능한 더 작은 논리적 PR들로 나누는 것을 도울 적합한 리뷰어를 찾을 수 있습니다.
  • 팀에게 여유가 없거나, 팀 구성원이 해당 규모의 변경을 있는 그대로 받아들일 준비가 되어 있지 않거나, 그럴 의향이 없거나, 그럴 수 없는 경우가 있습니다. 이런 경우에는 팀이 보류 또는 종료를 결정하고, 그 이유를 설명하며 PR 작성자에게 해당 결정을 명확히 전달해야 합니다. PR이 여러 달 동안 정체되다가 결국 거부되는 것은 매우 낙담스러운 일입니다.

리뷰의 기술적 측면

컴파일러 및 관련 크레이트에 반영되는 모든 PR은 해당 코드에 대해 지식이 있는 최소 한 명 이상에 의해 리뷰되어야 합니다.

PR이 열리면 PR 설명에 r? @username을 포함하여 리뷰어를 요청할 수 있습니다. 그렇게 하지 않으면 rustbot이 영향을 받은 파일에 따라 결정된 리뷰어 후보 풀에서 자동으로 누군가를 배정합니다.

나중에 r? @username 댓글을 남겨 다른 사람에게 리뷰를 요청하는 것이 일반적입니다. 이렇게 하면 PR이 재할당되기도 합니다.

예를 들어 여러 리뷰어에게 리뷰를 요청하는 것도 가능합니다.

Rolling both a T-compiler and T-bootstrap reviewer as this PR contains both
compiler and bootstrap changes.

r? compiler
r? bootstrap

bors

우리는 PR을 직접 병합하지 않습니다. 대신 저희는 bors를 사용합니다. bors 권한을 가진 자격 있는 리뷰어(예: 컴파일러 팀 구성원)가 @bors r+와 같은 댓글을 남길 것입니다. 이는 그들이 PR을 승인했음을 나타냅니다.

bors 권한을 가진 사람은 @bors r=username 명령을 남길 수도 있습니다. 이는 PR이 이미 @username에 의해 승인되었음을 나타냅니다. 이는 리베이스 후에 흔히 이루어집니다.

마지막으로, 경우에 따라 @bors delegate+를 작성하여 PR을 “위임“할 수 있습니다. 이렇게 하면 PR 작성자나 위임받은 사용자가 위와 같은 @bors 명령을 실행하여 PR을 승인할 수 있습니다(단, 이 권한은 해당 단일 PR에만 한정됩니다).

되돌리기(Revert)

병합된 PR이 예상치 못한 유의미한 회귀를 유발한 것으로 밝혀지면, 가장 좋은 정책은 이를 신속히 되돌린 뒤 수정 사항과 회귀 테스트가 추가되면 다시 반영하는 것입니다.

이 경우 “유의미한 회귀“는 되돌리기를 승인하는 사람의 판단에 달려 있습니다.

되돌리기가 정당한지 고려할 기준은 다음과 같습니다.

  • stable 또는 그 밖의 중요한 기능에서 코드 컴파일을 중단시키거나, 런타임 동작을 바꾸거나, 실제 사용 코드에서 (기본적으로 경고 이상 수준의) 린트를 잘못 트리거하는 버그. 특히 불안정한 기능 게이트 없이도 버그에 도달할 수 있는 경우.
  • 버그나 변경 사항(ICE 포함)이 특히 발생시키기 쉬운 경우.
  • 버그나 변경이 기여자 경험을 크게 저하시키는 경우.
  • 테스트가 불안정하고 신뢰할 수 없는 경우.

이러한 기준이 의심스러울 때, 특히 실제 코드에 영향이 있을 때는 PR을 되돌리십시오. 이는 세 가지 이점이 있습니다.

  1. 이는 최첨단 사용자(특히 nightly나 beta 사용자)가 HEAD를 계속 사용하고 버그를 보고할 수 있게 하며, 새로운 버그가 어디서 유입되었는지에 대해 더 높은 확실성을 갖게 합니다.
  2. 원래 PR 작성자와 팀에게서 부담을 덜어주어, 누구도 즉시 고쳐야 한다는 압박을 느끼지 않도록 합니다.
  3. 이는 중대한 버그나 회귀가 다른 nightly/beta/stable 빌드에 도달하는 것을 막을 수 있습니다.

되돌리기 전에, PR이 상당히 높은 확실성으로 회귀를 유발했음이 입증되어야 합니다(예: 커밋에 대한 이분 탐색, 하나 이상의 컴파일러 팀 구성원이 이 PR을 지목한 nightly 빌드에 대한 이분 탐색, 또는 관련자 모두에게 단순히 명백한 경우). 이슈를 고치는 것이 특히 중대하거나 시급한 경우에만 확신이 낮더라도 되돌립니다.

리버트 생성하기

리버트 커밋은 git CLI를 사용하여 생성한 다음 풀 리퀘스트로 업로드할 수 있습니다:

$ git revert -m 1 $COMMIT_HASH

여기서 $COMMIT_HASH는 병합 상태 메시지 옆에서 찾을 수 있습니다:

git이 생성한 기본 커밋 제목과 메시지에 만 의존하지 마십시오. 대신 되돌리기 커밋의 제목을 의미 있게 붙이고, 회귀를 유발한 관련 PR에 링크하십시오. 전체 또는 부분적으로 리버트되는 특정 PR로 링크를 거십시오. 관련 이슈와 논의로 링크를 거십시오. 리버트되는 커밋 해시를 보존하십시오.

리버트 커밋 제목 및 메시지 예시

Revert #131669 due to ICEs

Revert <https://github.com/rust-lang/rust/pull/131669> due to ICE
reports:

- <https://github.com/rust-lang/rust/issues/134059> (real-world)
- <https://github.com/rust-lang/rust/issues/134060> (fuzzing)

The changes can be re-landed with those cases addressed.

This reverts commit 703bb982303ecab02fec593899639b4c3faecddd, reversing
changes made to f415c07494b98e4559e4b13a9c5f867b0e6b2444.

원래 PR의 작성자와 리뷰어에게 무슨 일이 일어나고 있는지 알 수 있도록 태그하는 것이 예의입니다. 리버트 PR 설명에는 다음 메시지 템플릿을 사용할 수 있습니다:

Reverts rust-lang/rust#123456
cc @author @reviewer

This revert is based on the following report of a regression caused by this PR:
<link to issue or comment(s)>

In accordance with the compiler team [revert policy], PRs that cause meaningful
regressions should be reverted and re-landed once the regression has been fixed
(and a regression test has been added, where appropriate).
[revert policy]: https://forge.rust-lang.org/compiler/reviews.html#reverts

Fear not! Regressions happen. Please rest assured that this does not
represent a negative judgment of your contribution or ability to contribute
positively to Rust in the future. We simply want to prioritize keeping existing
use cases working, and keep the compiler more stable for everyone.

r? compiler

되돌리기 커밋으로 회귀가 실제로 해결되었는지 확인하기 위해 별도의 커밋에 임시 회귀 테스트를 포함해 주십시오. 다시 반영할 때, 이 임시 회귀 테스트는 개선된 테스트 커버리지에 따라 적절히 조정되거나 제거될 수 있습니다.

r+ 권한이 있다면 리버트를 셀프 승인할 수 있습니다. 단 리버트가 깔끔하고 그 자체로 새로운 리그레션을 일으킬 가능성이 낮은 경우에 한하며, 리버트가 “병보다 약이 더 나쁜” 경우가 아닌지 확인하십시오. 사소하지 않은 경우, 원래 리뷰어나 r? compiler를 통한 다른 컴파일러 리뷰어의 리뷰를 기다려 주십시오. 사안이 더 긴급하다면 #t-compiler에서 문의할 수 있습니다.

일반적으로 리버트는 우선순위를 높여야 하며, 리버트 대상 PR의 rollup 상태와 일치시켜야 합니다. 롤업이 아닌 PR이 성능에 영향을 미치지 않는 것으로 밝혀지면 rollup=always로 표시할 수 있습니다. 리버트 작성자는 롤업을 작성하는 기여자들과 조율하여 롤업 일정을 조정하거나, 적절한 경우 롤업 사이에 리버트 PR을 끼워 넣을 수 있습니다.

전방 수정(Forward fixes)

회귀를 해결하기 위해 회귀를 유발한 PR을 되돌리는 대신, 원래 PR을 전체적으로 되돌리지 않고 작은 방식으로 보완하는 후속 PR을 올리고 싶은 유혹이 종종 있습니다. 그러나 실제 사용자가 영향을 받았다고 보고한 경우, 다음 중 하나가 사실이 아닌 한 이러한 방식은 강력히 권장되지 않습니다:

  • 신뢰도 높은 수정이 이미 bors 큐에 있는 경우.
  • 회귀가 릴리스 브랜치(beta 또는 stable)에 도달하여 [백포트]가 필요한 경우. 백포트의 경우 종종 “가능한 한 작은 변경“이 요구됩니다(수정이 새로운 회귀를 유발하지 않도록 하기 위함입니다). 문제가 된 PR은 메인 브랜치에서 여전히 리버트될 수도, 되지 않을 수도 있습니다. 이는 r+할 수 있는 사람의 재량에 맡겨집니다.

PR이 리버트되는 것이 큰 후퇴처럼 느껴질 수 있지만, 대부분의 경우 수정이 확인되면 PR을 리랜드하는 것이 훨씬 쉽습니다. 리버트가 랜딩되도록 허용하면 여러분과 리뷰어가 서둘러 대응해야 한다는 압박이 줄어들고, 이슈를 완전히 해결할 시간을 확보할 수 있습니다. 이는 또한 한 걸음 물러나 테스트 커버리지를 재평가할 기회이기도 합니다.

롤업

모든 리뷰어는 PR이 [롤업]의 일부가 되어야 하는지 여부를 명시적으로 표시하도록 강력히 권장됩니다. 이는 보통 @bors r+ $ROLLUP_STATUS로 PR을 승인하거나 @bors $ROLLUP_STATUS를 사용할 때 이루어지며, 여기서 $ROLLUP_STATUS는 다음 중 하나로 대체됩니다.

  • rollup=always: 이러한 PR들은 테스트를 깨뜨리거나 성능에 영향을 줄 가능성이 매우 낮습니다. 예시 시나리오:
    • 변경 사항이 빌드를 실패시킬 가능성이 매우 낮은 문서, 주석 등에 국한됩니다.
    • 변경 사항이 성능에 영향을 줄 수 없습니다.
    • 여러분의 PR이 문제를 일으킬 수 있거나 동작을 변경하는 변경 사항을 반영하지 않습니다.
      • 다만 다른 변경 사항 없는 기능 안정화는 롤업해도 무방할 가능성이 높습니다.
    • 확신이 서지 않으면 이 옵션을 사용하지 마십시오!
  • rollup=maybe: @bors r+가 롤업 상태를 전혀 지정하지 않을 경우의 기본값입니다. 변경 사항이 테스트를 깨뜨리지 않는다는 확신이 다소 부족한 경우 이를 사용하십시오. 다른 범주 중 어느 것에 해당하는지 확신이 서지 않는 경우에도 사용할 수 있습니다. 이것이 기본값이므로, 이전 명령의 롤업 수준을 해제하는 경우가 아니라면 보통 명시적으로 지정할 필요가 없습니다.
  • rollup=iffy: 약간 위험한(즉 “maybe“보다 더 위험한) PR에 이를 사용하십시오. 예시 시나리오:
    • PR이 크고 비추가적인 경우(참고: 완전히 새로운 테스트 2000줄을 추가하는 것은 롤업해도 괜찮습니다).
    • 일반적인 PR 검사로는 확인되지 않는 플랫폼별 변경 사항이 있는 경우입니다.
    • MIR 마이그레이트 모드의 영향을 받을 수 있는 경우입니다.
  • rollup=never: 이는 롤업에 절대 포함되어서는 안 됩니다. 예시 시나리오:
    • 성능에 영향을 줄 수 있는 경우입니다.
    • 불분명한 회귀를 유발할 수 있는 경우(이 PR을 구체적으로 이분 탐색하고 싶을 것이며, 롤업에서는 원인으로 식별하기 어려울 것입니다).
    • 실패할 가능성이 높은 경우입니다.
    • 그 밖에 롤업하기에 위험한 경우.
      • 다음 항목과 지나치게 얽혀 있는 경우입니다.
      • LLVM 또는 코드 생성
      • 부트스트랩 또는 빌드 시스템
      • build-manifest
  • rollup: 이는 rollup=always와 동일합니다.
  • rollup-: 이는 rollup=maybe와 동일합니다.

rollup=iffy 또는 rollup=never를 설정할 때는, 그 이유가 명확하지 않다면 왜 이를 선택했는지에 대한 간단한 근거를 승인 코멘트에 포함하십시오.

우선순위

리뷰어는 우선순위를 설정하는 대신 위에 나열된 롤업 상태 중 하나를 설정하는 것이 권장됩니다. Bors는 롤업 상태(never가 가장 높은 우선순위이고 always가 가장 낮은 우선순위)와 PR의 경과 시간을 기준으로 자동 정렬합니다. 우선순위를 변경하는 경우, 다른 PR과의 공정성과 긴급성 사이의 균형을 최선의 판단으로 맞춰 주십시오.

다음은 우선순위 설정에 대한 지침입니다:

  • 1-5
    • P-high 이슈 수정
    • toolstate 수정
    • 위 항목을 포함하는 되돌리기
    • beta로 지명된 풀 리퀘스트
    • 서브모듈/서브트리 업데이트
  • 5 이상
    • P-critical 이슈 수정
  • 10 이상
    • 비트롯(bitrot)이 발생하기 쉬운 풀 리퀘스트(특히 많은 파일을 건드리는 매우 큰 것)
    • 긴급한 풀 리퀘스트(예: 긴급한 되돌리기)
    • beta 백포트
  • 20 이상
    • 모든 롤업보다 앞서 처리되어야 하는 높은 우선순위
    • 대기열 내 다른 풀 리퀘스트에 의해 다시 깨질 위험이 높은 것을 수정하거나 변경하는 경우
  • 1000
    • 절대적으로 중요한 수정
    • 릴리스 승격

우선순위를 설정할 때, 그 이유가 명확하지 않은 경우 승인 코멘트에 이를 선택한 이유를 간단히 포함해 주십시오.

r+에 대한 기대사항

bors 권한은 이분법적입니다: 봇은 여러분이 어떤 코드에 익숙하고 어떤 코드에 익숙하지 않은지 알지 못합니다. 따라서 신중하게 사용해야 합니다. 잘 알지 못하는 코드에 r+를 하지 마십시오 – 그런 코드를 리뷰하는 것은 분명히 가능하지만, 최종 r+는 다른 사람에게 넘기도록 하십시오.

마찬가지로, 리뷰를 수행한 당사자가 아니고, 리뷰가 이루어진 이후 코드가 실질적으로 변경되지 않았으며, 해당 인물이 다른 기여자가 자신을 대신하여 r=을 사용해도 좋다고 명시적으로 밝힌 경우가 아니라면, 결코 r=username 명령을 실행하지 마십시오.

리베이스는 괜찮으며 종종 필요하지만, 기능상의 변경은 일반적으로 재리뷰가 필요합니다. PR 작성자가 개별 리뷰 코멘트에 답하는 것에 더해 마지막 리뷰 이후 변경된 사항에 대한 간단한 요약을 작성해 주면 리뷰어에게 매우 도움이 됩니다.

봇 사용에 관한 bors 문서를 참고하십시오.

리뷰의 사회적 측면

무엇보다도 PR 작성자와 컴파일러 리뷰어 모두 행동 강령을 준수할 것이 기대됩니다. 간단히 말해, 리뷰어는 변경 사항에 동의하지 않더라도 PR 작성자를 존중해야 합니다.

리뷰어는 PR 작성자의 관점에서도 문제를 고려하도록 권장됩니다. 절차상의 이유나 리뷰어의 여력 부족으로 인해 어떤 해결도 없이(컴파일러가 현재로서는 그러한 변경을 받아들일 준비가 되어 있지 않을 수 있다는 결론도 해결에 포함되지만, 그런 경우에도 PR 작성자에게 기여에 대해 감사를 표해야 합니다) 몇 달간 변경 사항이 정체되고 계속해서 병합 충돌이 누적된다면, 매우 답답한 상황이 될 수 있습니다.

논의가 격해지고 있다면 모더레이션 팀에 개입을 요청하십시오.