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. 근거를 더욱 유용하게 만들기 위해, 작성자는 잠재적인 쟁점, 감수해야 했던 절충, 검토했던 대안적 접근 방식, 관련 문서, 논의 및 맥락 등을 나열할 것을 권장합니다.
    • 코드 리뷰는 어려운 일이며, 리뷰어에게는 리뷰에 쓸 수 있는 시간이 제한되어 있습니다. 리뷰어가 풀 리퀘스트의 의도와 맥락을 직접 짜맞추지 않아도 되도록 하여 리뷰 과정을 빠르게 시작할 수 있게 하면, 속도가 빨라질 뿐만 아니라 리뷰의 품질도 향상됩니다.
  • 리뷰어는 자신이 해당 변경 사항을 승인하기에 적합한 사람인지 잘 판단할 수 있어야 합니다.
    • 리뷰 대상 코드에 대한 지식은 이 질문에 답하기 위한 당연한 기준이지만 유일한 기준은 아닙니다.
    • 절차 측면에서 리뷰어는 다음 사항도 판단해야 합니다.
      • 리뷰어가 단독으로 결정할 수 있습니까?
      • 해당 PR이 승인 절차를 거쳐야 합니까?
      • 해당 PR에 다른 팀, 특히 t-lang의 리뷰 및/또는 승인이 필요합니까?
      • 변경 사항이 stable 코드를 깨뜨리거나 의도하지 않은 새로운 코드를 허용하기 시작할 수 있습니까? PR에 위험 요소가 있다면, 충분히 정당화됩니까? 변경 사항에 대해 Crater 실행을 통한 생태계 영향 평가가 필요합니까?
      • 해당 PR이 상당한 성능 변화를 가져옵니까? 성능 회귀가 발생할 수 있다면, 그것이 정당화됩니까? 해당 PR에 성능 측정 실행이 필요합니까?
      • 리뷰어가 충분히 철저하게, 그리고 적시에 리뷰를 수행할 수 있습니까?
      • 리뷰어가 충분히 편향되지 않은 관점을 제공할 수 있을 만큼 공정합니까? 예를 들어 공동 저작(리뷰어가 PR에 상당히 중요한 변경을 가한 경우)이나 기타 이해 상충으로 인한 문제는 없습니까?

리뷰 체크리스트

다음 질문 목록은 리뷰어와 PR 작성자 모두가 PR을 좋은 상태로 만들고 위의 기준을 충족하는 데 도움이 됩니다:

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

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

리뷰어를 위한 체크리스트

  • 제가 이 PR을 리뷰하기에 적합한 사람입니까:
    • 이 PR의 변경 사항이 t-compiler의 관할에 속합니까?
    • 제가 코드를 충분히 잘 이해하고 있습니까?
    • 명확하지 않은 부작용을 발견할 수 있겠습니까?
    • 이 PR로 인해 생긴 버그를 제가 고칠 수 있겠습니까?
    • 적시에 리뷰할 수 있습니까?
    • 어떤 이유로든 PR을 빨리 승인해야 한다는 압박을 느끼고 있습니까?
    • 제가 충분히 공정합니까?
  • 병합하기 전:
    • PR 제목과 설명이 여전히 정확합니까?
    • 커밋 이력이 충분히 깔끔합니까? PR 이력에 “fix typo” 커밋이 16개나 있을 필요는 없습니다.
    • PR이 관련 이슈를 올바르게 닫습니까, 아니면 잘못 닫습니까?
  • 다른 관련 팀의 리뷰어를 배정해야 합니까?

흔한 상황에 대처하기 위한 지침

대부분의 경우 이 정책을 어떻게 적용할지는 상식으로 충분히 판단할 수 있습니다. 그러나 때로는 어떻게 진행해야 할지 바로 명확하지 않은 모호한 영역이 있습니다. 이 절에서는 몇 가지 흔한 사례와 함께 각 사례에 대처하는 방법에 대한 지침을 제시합니다.

제가 리뷰하기에 적합하지 않은 것 같습니다. 이제 어떻게 해야 합니까?

(rustbot 등을 통해) PR이 (무작위로) 배정되었지만 리뷰하기가 부담스럽게 느껴지는 것은 지극히 정상적인 일입니다. 구체적인 경우에 따라 다음과 같이 할 수 있습니다.

  • 변경 사항이 매우 크거나 논란의 여지가 있어 보인다면, 작성자에게 적절한 승인 절차를 거치도록 권하는 것을 고려하십시오.
  • 리뷰에 딱 맞는 사람을 알고 있다면, r? @<github-name>로 그 사람을 배정하십시오. 그 사람에게 리뷰를 맡아 줄 수 있는지 묻는 댓글을 남기는 것이 예의입니다. 다만 그 사람이 실제로 맡을 수 있는지 미리 확인할 필요는 없습니다.
  • 변경 사항이 그리 복잡하지 않고, 무작위로 다시 배정될 다른 컴파일러 리뷰어도 이 PR을 어려워할 것으로 예상되지 않는다면, r? compiler로 컴파일러 리뷰어를 무작위로 다시 배정할 수 있습니다.
  • 변경 사항이 복잡하거나, 다른 컴파일러 리뷰어를 무작위로 배정해도 재배정만 여러 번 반복될 것으로 예상된다면, #t-compiler/private에 스레드를 열어 팀의 다른 구성원에게 이 PR을 리뷰할 수 있는 사람이 있는지, 더 나아가 팀이 이 변경 사항을 받아들이는 것 자체에 동의하는지 물어보아야 합니다.
  • 변경 사항이 다른 팀을 대상으로 한다면, 해당 팀의 리뷰어를 배정하십시오(예: 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이 좋은 상태가 되도록 돕는 것이 권장됩니다.

일반적으로 이런 경우에는 해당 분야를 잘 아는 사람에게 두 번째 의견을 구하는 것이 좋습니다. 멘토가 놓쳤을 수 있는 부분이나 사각지대를 발견할 가능성을 높이기 위해서입니다.

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

때로는 더 이상 아무도 이해하지 못하는 코드에서 버그가 발견되기도 합니다. 원래 작성자와는 연락이 닿지 않고, 제안된 수정이 어떤 영향을 미칠지 가늠하기도 어렵습니다. 이런 경우 리뷰어는 PR에 I-compiler-nominated를 지정하거나(계속 주 리뷰어를 맡으려는 경우), 컴파일러 팀 리드를 이슈에 배정하고 S-waiting-on-team 레이블을 추가하는 것이 좋습니다.

어느 경우든 PR은 주간 트리아지 회의에서 다뤄집니다. 또한 수정하려는 문제에 대한 설명, 불분명한 점, 잠재적 위험, 검토한 대안 등 이슈에 대한 정보를 최대한 많이 모아 문서로 남기는 것이 특히 중요합니다. 추적 이슈를 열어 해당 영역을 제대로 이해하지 못하고 있다는 사실과 구체적인 질문, 우려 사항, 버그를 기록해 두는 것도 좋습니다. 이 추적 이슈는 컴파일러 팀 구성원들이 해당 영역을 다시 잘 이해하게 되면 해결할 수 있습니다.

리뷰어는 PR 작성자에게 이러한 정보를 코드 주석이나 PR 메시지(git 커밋 기록의 일부가 됩니다) 또는 둘 모두에 추가해 달라고 요청해야 합니다.

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

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

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

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

이러한 API에는 해당 API가 어떤 외부 사용자와 관련이 있고 어떤 목적으로 쓰이는지 밝히는 문서 주석을 달도록 요구하십시오.

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

이로 인해 내부용이어야 할 컴파일러 API가 눈에 띄지 않게 외부 사용자에게 묶일 수 있다는 점에 유의하십시오. (rust-lang/ 프로젝트가 아닌) 외부 사용자에게는 리팩터링을 방해하는 등 컴파일러에 상당한 유지 보수 부담을 주지 않는 한에서만 이러한 편의를 제공할 수 있으며, 엄격한 안정성은 보장하지 않는다는 점을 전달하십시오.

PR이 매우 크고 복잡한 경우

리뷰어가 매우 크고 복잡한 PR까지 감당해야 하는 것은 아닙니다. 기여자는 리뷰가 가능하도록 작업을 나누어야 합니다. 예를 들어 각각 논리적으로 더 독립적이고 이해하기 쉬운 여러 개의 PR로 나눌 수 있습니다. 일반적으로 영향이 큰 변경을 제출하기 전에 기여자는 관련 팀과 설계를 미리 논의해야 합니다. 따라서 그러한 논의를 참조로 제시하는 것은 기여자의 책임입니다.

확신이 서지 않을 때는 Zulip 스레드를 통하거나 컴파일러 트리아지 회의에 상정하거나 둘 다 해서 PR을 팀에 알리십시오. 그러면 팀이 다음 중 어떻게 할지 결정할 수 있습니다.

  • 팀은 PR 작성자가 큰 변경을 더 작은 논리적 PR로 나누도록 도와줄 적합한 리뷰어를 찾을 수 있습니다. 나눈 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 하나로 제한됩니다).

되돌리기

병합된 PR이 예상치 못한 유의미한 회귀를 일으킨 것으로 밝혀지면, 가장 좋은 방침은 이를 신속히 되돌리고 나중에 수정 사항과 회귀 테스트가 추가되었을 때 다시 반영하는 것입니다.

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

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

  • stable 기능이나 그 밖의 중요한 기능의 버그로 인해 실제 코드가 컴파일되지 않게 되거나, 런타임 동작이 바뀌거나, (기본 경고 수준 이상의) 린트가 잘못 발생하는 경우입니다. 특히 불안정 기능 게이트 없이도 해당 버그에 도달할 수 있는 경우입니다.
  • 버그나 변경 사항(ICE 포함)이 ICE 포함)가 특히 쉽게 발생하는 경우입니다.
  • 버그나 변경 사항이 기여자 경험을 크게 저하하는 경우입니다.
  • 테스트가 불안정하여 신뢰할 수 없는 경우입니다.

이러한 기준에 해당하는지 확실하지 않을 때, 특히 실제 코드가 영향을 받는다면 PR을 되돌리십시오. 이렇게 하면 세 가지 이점이 있습니다.

  1. 최신 개발 버전을 쓰는 사용자(특히 nightly 또는 beta 사용자)가 새 버그가 어디서 유입되었는지 더 확실히 알 수 있는 상태에서 HEAD를 계속 사용하고 버그를 보고할 수 있습니다.
  2. 원래 PR 작성자와 팀의 부담을 덜어 주어, 누구도 이를 즉시 고쳐야 한다는 압박을 느끼지 않게 됩니다.
  3. 심각한 버그나 회귀가 다음 nightly/beta/stable 빌드에 포함되는 것을 막을 수 있습니다.

PR을 되돌리기 전에 그 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을 끼워 넣을 수 있습니다.

후속 수정

회귀를 일으킨 PR을 되돌리는 대신, 전체 변경 사항은 되돌리지 않고 원래 PR을 조금씩 보완하는 후속 PR을 올려 회귀를 해결하고 싶어질 때가 많습니다. 그러나 실제 사용자가 영향을 받았다고 보고했다면, 다음 중 하나에 해당하지 않는 한 이렇게 하지 않기를 강력히 권합니다.

  • 신뢰도 높은 수정이 이미 bors 큐에 들어가 있는 경우.
  • 회귀가 릴리스 브랜치(beta 또는 stable)에 들어가 백포트가 필요한 경우. 백포트에는 수정이 새로운 회귀를 일으키지 않도록 “가능한 한 가장 작은 변경“이 바람직한 경우가 많습니다. 문제의 PR을 메인 브랜치에서 여전히 되돌릴지 여부는 해당 PR을 r+할 수 있는 사람의 재량에 맡깁니다.

PR이 되돌려지면 크게 후퇴한 것처럼 느껴질 수 있지만, 대부분의 경우 수정이 확인된 뒤 PR을 다시 반영하는 편이 훨씬 쉽습니다. 되돌리기가 반영되도록 두면 여러분과 리뷰어가 서둘러 대응해야 한다는 부담을 덜 수 있고, 이슈를 충분히 해결할 시간을 확보할 수 있습니다. 또한 한발 물러서서 테스트 커버리지를 다시 점검하는 기회이기도 합니다.

롤업

모든 리뷰어에게 PR을 롤업에 포함해야 하는지 여부를 명시적으로 표시할 것을 강력히 권장합니다. 이 표시는 보통 PR을 승인할 때 @bors r+ $ROLLUP_STATUS를 사용하거나 @bors $ROLLUP_STATUS를 사용하여 하며, 이때 $ROLLUP_STATUS는 다음 중 하나로 대체합니다.

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

rollup=iffy 또는 rollup=never를 설정할 때 그 이유가 분명하지 않다면 왜 이를 선택했는지 설명하는 짧은 이유를 승인 댓글에 포함하십시오.

우선순위

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

다음은 우선순위 설정에 관한 몇 가지 지침입니다.

  • 1-5
    • P-high 이슈 수정
    • Toolstate 수정
    • 위 항목을 포함하는 되돌리기(revert)
    • beta로 상정된 PR
    • 서브모듈/서브트리 업데이트
  • 5+
    • P-critical 치명적인 이슈 수정
  • 10+
    • 비트로트(bitrot)가 발생하기 쉬운 PR(특히 많은 파일을 수정하는 매우 큰 PR)
    • 긴급한 PR(예: 긴급한 되돌리기)
    • beta 백포트
  • 20+
    • 모든 롤업보다 먼저 처리되어야 하는 높은 우선순위
    • 큐에 있는 다른 PR 때문에 다시 망가질 위험이 높은 부분을 수정하거나 변경하는 경우
  • 1000
    • 절대적으로 중요한 수정
    • 릴리스 승격

우선순위를 설정할 때 그 이유가 명확하지 않다면, 이 우선순위를 선택한 이유를 설명하는 짧은 사유를 승인 코멘트에 포함하십시오.

r+에 대한 기대 사항

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

마찬가지로, 그 사람이 리뷰를 마쳤고, 리뷰 이후 코드가 크게 바뀌지 않았으며, 다른 기여자가 자신을 대신해 r= 명령을 사용해도 된다고 그 사람이 명시적으로 밝힌 경우가 아니라면 r=username 명령을 절대 발행(이슈)하지 마십시오.

리베이스는 괜찮으며 종종 필요하지만, 기능상의 변경은 일반적으로 다시 리뷰를 받아야 합니다. PR 작성자가 개별 리뷰 코멘트에 응답하는 것과 더불어 마지막 리뷰 이후 변경된 내용을 간단히 요약해 준다면 리뷰어에게 매우 도움이 됩니다.

봇 사용법은 bors 문서를 참고하십시오.

리뷰의 사회적 측면

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

리뷰어는 PR 작성자의 관점에서도 사안을 고려하는 것이 권장됩니다. 변경 사항이 절차상의 이유나 리뷰어의 여력 부족으로 몇 달 동안 아무런 결론 없이(현재로서는 컴파일러가 그러한 변경을 받아들일 준비가 되어 있지 않을 수 있지만 그래도 PR 작성자의 기여에 감사를 표한다는 결론도 포함합니다) 멈춰 있고 병합 충돌이 계속 쌓인다면, 매우 좌절스러울 수 있습니다.

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