오늘의 영어 표현 30/30 · 단계: 머지 뒤. 예문은 모두 이 글을 위해 지어낸 것입니다. 실제 저장소의 댓글을 옮긴 것이 아니며, 브랜치와 번호는 예시입니다.
목차
한눈에 보기
| 표현 | Could we backport this to release-1.4? / Is this a candidate for a cherry-pick? |
| 뜻 | 이 수정을 release-1.4 에도 옮겨 넣을 수 있을까요? |
| 쓰는 자리 | 병합된 PR 의 댓글, 이슈, 릴리스 관련 채널 |
| 공손함 | 정중한 요청. 결정은 메인테이너가 합니다 |
1. 뜻과 뉘앙스
backport 는 back(뒤로)과 port(옮기다, 이식하다)를 합친 말로, 새 버전에서 고친 내용을 예전 버전에 옮겨 넣는 것입니다. 오픈소스에서는 main 에 병합된 수정을 이미 나간 릴리스 브랜치(release-1.4 등)에 옮겨, 다음 패치 릴리스(1.4.x)에 싣는 일을 말합니다.
Kubernetes 는 같은 일을 cherry pick 이라고 부릅니다. Kubernetes 의 cherry pick 문서에 따르면, 이것은 이미 master 에 병합된 변경을 릴리스 브랜치로 옮기는 일이고, 대개 패치 릴리스로 보안 수정이나 심각한 버그 수정을 내보내기 위해 합니다. 요청하는 사람은 저장소의 hack/cherry_pick_pull.sh 스크립트로 대상 브랜치마다 따로 cherry pick PR 을 만들고, 지원 중인 가장 최신 릴리스 브랜치부터 오래된 쪽으로 진행합니다. 새 cherry pick PR 에는 do-not-merge/cherry-pick-not-approved 라벨이 붙고, 릴리스 관리자가 승인한 뒤에야 병합됩니다. 다른 프로젝트는 봇 명령이나 라벨로 같은 일을 하기도 하므로 CONTRIBUTING 문서를 확인합니다.
이 과정에서 알 수 있듯이 backport 는 당연히 해 주는 일이 아닙니다. 릴리스 브랜치는 안정성이 우선이라, 새 기능이나 위험한 변경은 받지 않는 것이 보통입니다. 그래서 요청할 때는 왜 필요한지를 반드시 적습니다. 보안 문제인지, 데이터 손실이나 업그레이드 실패 같은 심각한 버그인지, 영향을 받는 사용자가 많은지를 밝히면 메인테이너가 판단하기 쉽습니다. 요청의 주어를 we 로 쓰는 것(Could we ...?)도 「같이 판단해 보자」는 협조의 느낌을 줍니다.
2. 예문
상황 1: 병합된 PR 에 요청할 때
Thanks for fixing this! Could we backport it to release-1.4? Users on 1.4 hit this crash during upgrades, and there's no workaround.
there's no workaround 는 「우회 방법이 없다」로, backport 가 필요한 이유를 가장 짧게 전합니다.
상황 2: 대상인지 물을 때
Is this a candidate for a cherry-pick to the 1.3 and 1.4 branches, or is it too risky for a patch release?
candidate 는 「후보」입니다. too risky 라는 선택지를 함께 주면 메인테이너가 거절하기도 쉽습니다.
상황 3: 메인테이너가 답할 때
I'd rather not backport this one. It touches the API defaults, which we try to keep stable in patch releases. It'll be in 1.5.0.
거절에도 이유와 대안(다음 정식 릴리스)이 함께 옵니다.
3. 비슷한 표현과 차이
- Cherry-pick. Git 명령 이름에서 온 말로, 특정 커밋만 골라 다른 브랜치에 적용하는 것입니다. Kubernetes 처럼 backport 절차 자체를 이 이름으로 부르는 프로젝트도 있습니다.
- Patch release. backport 된 수정이 실려 나가는 릴리스(1.4.3 등)입니다. Will this be in the next patch release? 처럼 묻습니다.
- Forward-port. 반대 방향으로, 릴리스 브랜치에서 먼저 고친 것을 main 에 옮기는 일입니다. 드물지만 알아 두면 헷갈리지 않습니다.
4. 한국인이 자주 하는 실수
- Please apply this to old version too. 어느 버전인지, 왜 필요한지가 빠져 있습니다.
- 고친 문장: Could we backport this to release-1.4? It fixes a data loss bug that affects 1.4 users.
- Backport please!! 요청이 아니라 요구처럼 들립니다.
- 고친 문장: Would this be a good candidate for a backport?
- I want you to backport this. 결정권이 메인테이너에게 있다는 점을 무시하는 말투입니다.
- 고친 문장: Would you consider backporting this to the 1.4 branch?
5. 한 줄 연습
다음 한국어 문장을 병합된 PR 의 댓글로 바꿔 쓰십시오.
이 수정을 1.4 브랜치에도 넣을 수 있을까요? 1.4 를 쓰는 사용자도 같은 메모리 누수를 겪고 있습니다.
모범 답안
Could we backport this to the 1.4 branch? Users on 1.4 are hitting the same memory leak.
are hitting 은 「지금 겪고 있다」는 진행형으로, 문제가 현재 진행 중이라는 점을 전합니다. 사용자 수나 이슈 링크를 덧붙이면 더 설득력이 생깁니다.
티티 한마디. backport 는 부탁입니다. 왜 필요한지 한 문장을 붙이면, 메인테이너가 「예」라고 말하기 쉬워집니다. 서른 편을 함께해 주셔서 고맙습니다.
참고
- Kubernetes, Cherry Picks 문서: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md
- Git 문서, git-cherry-pick: https://git-scm.com/docs/git-cherry-pick