롤업 절차

배경

Rust 프로젝트에는 모든 풀 리퀘스트가 기본 브랜치에 푸시되기 전에 병합 후 테스트를 거쳐야 한다는 정책이 있습니다. PR 물량이 늘어남에 따라 이는 확장성이 떨어질 수 있으며, 특히 현재 Rust의 CI 소요 시간(약 3.5시간)이 긴 것을 감안하면 더욱 그렇습니다.

롤업을 소개합니다! 규모가 작거나, 성능에 민감하지 않거나, 플랫폼에 종속되지 않는 변경 사항에는 bors에 대한 rollup 명령을 표시합니다(@bors r+ rollup은 PR을 승인하고 롤업으로 표시, @bors rollup은 이미 승인된 PR을 표시, @bors rollup-은 롤업 표시를 해제). ’롤업 수행’이란 이러한 변경 사항들을 하나의 PR로 모아 한 번에 병합하는 것을 의미합니다. 롤업 명령은 always, maybe, iffy, never의 네 가지 값을 받습니다. 이러한 각 상태가 무엇을 의미하는지에 대한 안내는 리뷰 정책의 [롤업 섹션]을 참고하십시오.

Rust의 Bors queue에서 롤업 PR 목록을 볼 수 있으며, 이들은 ‘approved’ 큐의 맨 아래에 우선순위 ’rollup’으로 나열됩니다. 이는 큐에서 앞에 있는 모든 항목이 병합될 때까지 단독으로는 병합되지 않는다는 것을 의미합니다.

롤업 만들기

1. Bors queue의 인터페이스를 사용하여 풀 리퀘스트를 선택한 다음 “Create rollup” 버튼을 사용해 롤업 풀 리퀘스트를 만드십시오. (공정성에 관한 텍스트는 무시해도 됩니다.) 중요 참고 사항: the Rollups section의 리뷰 정책에 따라 rollup=always, rollup=maybe, rollup=iffy로 표시된 PR들을 추가 대상으로 고려하십시오. 특히 rollup=maybe와 rollup=iffy PR에 대해서는 무엇을 포함할지 결정할 때 더욱 신중해야 합니다. 회귀(버그 또는 성능 저하)의 위험을 감수하고 이를 겪는 일을 최대한 피하려고 노력해야 합니다. 또한 기여자들이 마땅히 rollup=never로 표시해야 할 때도 종종 그렇게 표시하는 것을 잊어버린다는 점을 고려하십시오. 따라서 풀 리퀘스트에 롤업 관련 태그가 명시적으로 붙어 있지 않을 때는 더욱 주의를 기울여야 합니다.

2. 풀 리퀘스트 스레드에서 다음 명령을 실행하십시오:

   @bors r+ p=5
   

3. 롤업이 실패하면 rust-log-analyzer가 제공하는 로그를 사용해 특정 PR로 실패 원인을 이분 탐색하고, @bors r-로 승인을 취소하십시오. 그런 다음 롤업 PR을 닫고, 문제가 된 PR을 제외한 채 **1.**부터 다시 시작하여 재생성하십시오. 롤업 PR 본문에는 (r-된 PR을 제외한) 기존 PR들로 롤업 UI를 자동으로 채우는 링크가 있습니다. 자세한 내용은 실패한 롤업을 참고하십시오.

4. 롤업이 성공하면 다음 롤업으로 진행할 수 있습니다(가끔씩 rollup=never PR도 진행되도록 해 주십시오).

풀 리퀘스트 선택하기

큐는 롤업 상태별로 정렬됩니다. 일반적으로 좋은 롤업은 (가능하다면) iffy PR 한두 개, 다수의 maybe(표시 없는) PR, 그리고 대량의 always PR로 구성됩니다. 롤업에는 rollup=never PR이 절대 포함되어서는 안 됩니다(bors가 이를 보장합니다).

롤업의 실제 절대적인 크기는 경험에 따라 달라질 수 있습니다. 롤업 작성을 처음 시작하는 사람은 iffy 1개, maybe 4개, always 5개를 포함하는 것으로 시작할 수 있지만, 더 경험이 많은 사람은 iffy 1~2개, maybe 8개, always 10개로 롤업을 만들 수도 있습니다! 대규모 롤업이 필요한 경우는 드물지만, 직관이 늘어날수록 롤업에 PR을 포함할 때 위험을 판단하는 능력도 나아질 것입니다.

PR의 롤업 상태를 낮추는 것을 주저하지 마십시오! rollup=always PR에 실패 가능성이 있다는 직감이 든다면 rollup=maybe 또는 rollup=iffy로 표시하십시오. 태그가 없는 maybe PR 중 상당수는 리뷰어가 롤업 가능 여부를 미처 고려하지 않았기 때문에 그렇게 분류된 경우이므로, 언제나 비판적인 시각으로 살펴볼 가치가 있습니다. 마찬가지로, 어떤 PR이 롤업을 실패하게 만들었다면 그 PR의 롤업 상태를 변경하는 것을 고려할 가치가 있습니다.

일반적으로 CI 구성이나 부트스트래핑 과정을 건드리는 PR은 대체로 iffy이며 신중하게 다루어야 합니다. 반면 단순히 문서를 편집하는 PR은 보통 rollup=always입니다.

같은 롤업에 큰 diff나 서브모듈 변경이 포함된 PR을 너무 많이 넣는 것은 피해야 합니다. 또한 큰 성능 영향이 있을 것으로 예상되는 풀 리퀘스트는 포함을 피하고, rollup=never로 표시하십시오.

이상적으로는 롤업이 성공하기를 바라기 때문에 iffy PR을 아예 포함하지 않고 싶은 유혹이 듭니다. 하지만 PR 큐가 하는 일은 PR을 테스트하는 것이지, 병합하는 것이 아니라는 점을 기억해 둘 필요가 있습니다. 따라서 iffy PR로 인해 롤업이 실패하는 것은 오히려 좋은 일인데, 그 PR은 어차피 언젠가는 테스트를 거쳐야 하고, 롤업에 포함되지 않았더라도 테스트하는 데 동일한 시간이 걸렸을 것이기 때문입니다. iffy PR에 관해 롤업을 바라보는 한 가지 방법은, 롤업이란 다른 여러 PR들이 어차피 iffy PR에 필요한 CI 주기에 편승하는 방법이라는 것입니다. 롤업이 iffy 풀 리퀘스트를 완전히 배제한다면, 결국 이러한 풀 리퀘스트가 큐에서 오랫동안 방치되는 결과가 생기는데, 이는 바람직하지 않습니다.

마찬가지로, never 풀 리퀘스트도 기회를 얻을 수 있도록 여유 CI 사이클을 남겨두어야 합니다! 롤업을 만드는 사람이 자신뿐이라면 큐를 주시하지 않는 시간대에 실행되도록 두는 것이 좋지만, 요즘은 여러 시간대에 걸쳐 롤업 작성자가 있으므로, 큐의 상대적 크기를 주시하면서 never PR을 위해, 특히 그것들이 쌓이고 있다면, 몇 번의 CI 주기를 따로 마련해 두는 것이 대개 최선입니다.

롤업에 있어 공정성을 유지하도록 노력하십시오: 롤업은 순서를 앞당기는 방법입니다. rollup=maybe 풀 리퀘스트의 경우, (섹션 맨 위에 있는) 가장 오래된 것을 포함하도록 노력하여, 더 새로운 풀 리퀘스트가 더 오래된 풀 리퀘스트를 완전히 앞지르지 않도록 하십시오. 롤업에 포함된 PR보다 오래된 모든 PR을 포함할 필요는 없지만, 가장 오래된 것은 포함하도록 노력하십시오. iffy에 관한 관점과 비슷하게, 롤업을 큐에서 가장 오래된 PR의 CI 주기에 다른 PR들이 편승하는 방법으로 바라보는 것이 유용합니다.

실패한 롤업

롤업이 실패한 경우, 실패가 우발적인 것이었다면(예: 네트워크 문제나 타임아웃으로 인한 것) @bors retry 명령을 실행하십시오. 우발적인 것이 아니었다면 문제가 된 PR을 찾아내어, rust-logs-analyzer 댓글 링크를 복사하고 Failed in <link_to_comment>, @bors r-라고 작성하여 큐에서 제외하십시오. 바라건대, 작성자나 리뷰어가 PR을 수정하기 위한 피드백을 주거나 문제가 없음을 확인해 줄 것입니다. 실패한 롤업 PR은 닫아도 됩니다.

문제가 되는 PR을 제거한 후에는 그것을 제외하고 롤업을 다시 생성하십시오(1번 참조). 그러나 때로는 문제가 된 풀 리퀘스트를 찾기 어려운 경우가 있습니다. 그런 경우에는 문제가 있다고 의심되는 PR을 직관적으로 피하여 롤업을 다시 생성하십시오. 또 다른 전략은 의심되는 PR들의 우선순위를 높이고 rollup=never(또는 iffy)로 표시하여 bors가 이를 단독으로 테스트하게 함으로써 가설을 기각하거나 확인하는 것입니다.

롤업이 계속 실패하는 경우 @bors rollup=never 명령을 실행하여 해당 PR을 롤업에 포함되지 않도록 할 수 있습니다.