레뷰어는 Thunderbird를 떠나지 않고 메일로 git 패치를 검토할 수 있습니다: 여전히 살아 있는 구식 방식의 흐름

코르뱅은 많은 젊은 개발자들이 완전히 간과하고 있는 패치 리뷰 프로세스를 다시 한 번 조명합니다: 리눅스 커널 스타일의 이메일 패치 리뷰입니다. Thunderbird를 떠나지 않고도 이 작업을 수행할 수 있는 프로젝트가 있으며, 그 중요성은 우리가 생각하는 것보다 더 큽니다.

구체적인 사례: 리눅스 커널, git, Emacs에 기여하기

GitHub와 GitLab만 사용해온 개발자에게는 이상한 질문처럼 들릴 수 있습니다: "대체 왜 이메일로 코드 리뷰를 해야 하나요?" 구체적인 답변: 현대 컴퓨팅의 핵심 프로젝트들—리눅스 커널(LKML), git 자체, Emacs, U-Boot, QEMU, Postgres(일부), 대부분의 BSD 프로젝트—는 기여를 받기 위해 웹 포지를 사용하지 않기 때문입니다. 전통적인 워크플로는 다음과 같습니다:

1. 기여자는 git format-patch를 실행하여 브랜치를 .patch 파일 시리즈로 변환합니다(커밋당 하나씩).
2. git send-email로 이 패치들을 공개 메일링 리스트에 보냅니다.
3. 유지 관리자와 동료들은 인라인 방식으로 응답합니다: > 접두사로 코드 줄을 인용하고 바로 아래에 댓글을 작성합니다. 이는 메일 클라이언트에서 진행되는 코드 리뷰입니다.
4. 기여자는 v2, v3 등을 보냅니다. 유지 관리자가 git am으로 시리즈를 최종 통합합니다.

이 워크플로는 웹 포지가 제공하지 못하는 객관적인 장점을 가집니다: 검색 가능한 공개 아카이브(lore.kernel.org, marc.info), GitHub 계정 없이 참여 가능, "한 번 작성하고 여러 번 읽기" 원칙 준수.

Korben이 소개하는 도구: thunderbird-patch-review

GitHub의 리뷰—문법 강조, 줄별 댓글, Approve/Request changes—는 이메일 리뷰를 읽기 어렵게 만드는 세대를 만들었습니다. 결과적으로 커널 기여의 진입 장벽이 높아지고 있지만, git send-email은 검증된 오래된 도구입니다.

Marc Coquand는 팀을 메일 우선 워크플로에 참여시키고자 했으며, 특이한 도구를 강요하지 않았습니다. 그는 thunderbird-patch-review라는 Thunderbird 확장 프로그램을 개발했습니다: 패치 시리즈가 포함된 메일이 도착하면 확장 프로그램은 편안한 리뷰 뷰를 제공하는 버튼을 제공합니다—패치 색상 강조, 대상 파일로 이동, 로컬 패치 적용 및 테스트, 올바른 인용 규칙에 따른 인라인 응답. 이 도구의 목적은 GitHub를 대체하는 것이 아니라, 해당 플랫폼을 사용하지 않는 프로젝트에 참여할 수 있도록 하는 것입니다.

현재 저장소와 최신 버전을 찾으려면 Korben의 기사(출처 링크 참조)를 참고하세요. Marc Coquand의 저장소를 직접 가리킵니다—메모리상의 URL을 인용하지 않습니다.

전체 파이프라인 구축 방법(Thunderbird 확장 외)

완전한 파이프라인을 재구축하려면:

• Git에 SMTP 구성: git config sendemail.smtpServer <서버>
• 커버 레터와 스레딩이 올바른 시리즈 준비: git format-patch -N HEAD~M에 cover-letter(--cover-letter)와 thread(--thread) 옵션 사용
• 시리즈 전송: git send-email에 to=list@vger.kernel.org와 cc=maintainer@example.org 옵션 사용(각각 -- 접두사 붙임)
• 수신 측: 받은 시리즈 적용 git am < email.mbox

완전히 분산된 워크플로로, 제3자에 의존하지 않습니다. 참고 문서는 git-scm.com의 git send-email(1)입니다.

기억해야 할 점

• 이메일 워크플로는 죽지 않았고, 중요합니다: 커널, git, Emacs, BSD의 워크플로입니다.
• Marc Coquand의 thunderbird-patch-review는 GitHub에 익숙한 개발자가 완전히 다른 방식을 채택하지 않고도 기여할 수 있게 해줍니다.
• 테스트 방법: 발신용 SMTP 계정 구성, 간단한 기여(예: 커널 문서 오타)로 git send-email 시도(LKML은 첫 패치에 매우 관대합니다).
• 보너스 철학: 이는 Git 리터러시 연습이기도 합니다—패치 이메일과 Git 커밋이 거의 동일한 객체라는 점을 이해하면 Git의 많은 동작이 clearer 해집니다.