패치 작성자를 위한 지침

다음은 마츠 씨가 직접 언급한 좋은 패치를 만드는 방법입니다.

이 지침은 Ruby-Core 메일링 리스트의 마츠 씨의 글에서 가져왔습니다.

• 패치당 하나의 수정사항 구현하기

  이는 대부분의 보류 중인 패치들이 갖고 있는 가장 큰 문제입니다. 여러 개의 버그를 수정하는 (또 여러 기능을 추가하는) 패치를 한 번에 보내면, 우리는 이를 다시 나눠서 적용해야 합니다. 이는 바쁜 개발자에게는 상대적으로 힘든 작업이 되기에, 이런 유형의 패치는 자주 보류되곤 합니다. 큰 패치를 보내지 말아주세요.

• 설명 제공하기

  가끔 어떤 문제를 고치는지에 대한 충분한 설명이 없는 패치가 들어오곤 합니다. 좀 더 나은 설명(패치가 고치는 문제점, 전제조건, 플랫폼 등)과 함께라면 패치가 더 일찍 병합될 수 있을 것입니다.

• 최신 리비전 기반으로 패치 작성하기

  고치려는 문제가 이미 최신 리비전에서 수정되었을 수 있습니다. 코드가 완전히 달라졌을 수도 있습니다. 패치를 제출하기 전에 서브버전 저장소에서 최신 버전(최신 개발 버전은 trunk 브랜치, 2.6 버전은 ruby_2_6 브랜치)을 받아 보세요.

• diff -u 사용하기

  우리는 diff -c나 다른 스타일보다 diff -u의 unified diff 스타일의 패치를 선호합니다. 그게 리뷰하기 훨씬 쉽습니다. 수정한 파일을 보내지 마세요. 직접 diff를 만들고 싶지 않습니다.

• 테스트 케이스 추가하기(선택 사항)

  패치가 테스트 케이스(test/*/test_*.rb에 패치하는 게 좋습니다)를 제공하면 작성자의 의도와 패치를 이해하는 데 도움이 됩니다.

추후에는 Git 스타일 push/pull 워크플로로 옮겨갈 수 있습니다. 하지만 그 전까진 위의 지침을 따른다면 낙심할 일을 줄일 수 있을 겁니다.