class: center, middle # 오픈소스 기여하기 비바리퍼블리카 이응준 --- # 오픈소스 기여 1. 버그 리포트 2. 패치 보내기 ✓ --- # 발표 내용 1. 언제 패치를 보내게 되는가 2. 어떻게 패치를 보내야 하나 3. 프로젝트에 패치 보내는 방법들 및 경험 사례 --- class: center, middle # 언제 패치를 보내게 되는가 --- ## 나에게 닥친 문제를 해결하기 위해 ### Case #1 - i18n-node 개발중인 제품이 특정 라이브러리의 문제로 윈도에서 설치가 안되는 치명적인 이슈가 생겨서, 해당 라이브러리에 그 문제를 해결하는 패치를 보냄 * https://github.com/mashpie/i18n-node/pull/25 ### Case #2 - simplesmtp, play-plugins SMTP 라이브러리가 네이버 메일을 잘 지원하지 않아 메일을 발송하지 못하는 문제를 겪어서, 이를 해결하고자 해당 라이브러리리에 이 문제를 수정하는 패치를 보냄 * https://github.com/andris9/simplesmtp/pull/7 * https://github.com/typesafehub/play-plugins/pull/38 --- ## 새로운 기능이 필요해서 ### Case #3 - Mattermost 사내에서 사용하는 채팅 서비스에 push 알림 기능이 필요해서 만들어 보냄 * https://github.com/mattermost/platform/pull/1869 --- ## 모두를 위해 ### Case #4 - freeciv 게임하는데 오타가 있음 * https://github.com/freeciv/freeciv/commit/f4361c198b46412a29d4922a558b925f1b3f7af9 ### Case #5 - urllib3 HTTP 서버가 Retry-After로 재시도할 시간을 정해주었을 때, 클라이언트가 그 시간 후 자동으로 재시도하는 기능이 필요하다. 나는 그냥 직접 구현해서 해결했지만 미래의 다른 사람이 같은 수고를 반복하지 않도록 오픈소스 라이브러리에 그 기능을 구현한다. * https://github.com/shazow/urllib3/pull/955 --- ## 해외 컨퍼런스 가고싶어서(?) ### Case #6 - Git Git Merge 2013 의 Developer Day는 컨트리뷰터만 참여할 수 있어서 못갔음. 그래서 Git에 패치 몇개 보내고 Git Merge 2015 때는 컨트리뷰터로 참가함. * https://github.com/git/git/commit/04953bc888e648dc22c172ffa74de1b2a08a209a --- class: center, middle # 어떻게 패치를 보내야 하나 --- class: center, middle # 어떻게 패치를 보내야 하나 프로젝트 웹사이트에 찾아가서 알아본다. --- ## 프로젝트 웹 사이트 찾는 법 1. "github 프로젝트이름"으로 구글링 2. "프로젝트이름"으로 구글링 --- ## 프로젝트 이름조차 모르겠을 때 제품 이름과 소스 코드를 받을 수 있는 프로젝트 이름이 다른 경우 * ls(1) - coreutils * chrome - chromium manpage나 위키백과를 확인한다. --- ## 패치 보내는 방법이 어디있는지 모를 때 보통 다음 둘 중 한 곳에 있다. 1. 웹 사이트의 어딘가에 2. 소스코드의 문서파일로 다음의 키워드로 웹 사이트를 찾아보거나 * Developer’s Guide * Contributing, Contributor's Guide * Community * Reporting bugs 다음과 같은 이름의 파일을 소스코드에서 찾아본다. * [README](https://github.com/spring-projects/spring-framework#contributing) * [CONTRIBUTING](https://github.com/spring-projects/spring-framework/blob/master/CONTRIBUTING.md) * [SubmittingPatches](https://github.com/git/git/blob/master/Documentation/SubmittingPatches) --- ## 패치 보내는 방법 안내가 없을 때 1. 우선 최신 버전의 소스코드를 받는다. (가급적 코드 저장소에서) 2. 코드를 고친다. 3. 패치를 보낸다. * 코드를 받은 곳이 Github이라면 PullRequest를 보낸다. * Github이 아니고 어떻게 보내야할지 잘 모르겠다면 그냥 패치파일로 만들어서 메일로 보내도 된다. --- ## 아무리 찾아봐도 없을 때 * 메일링 리스트를 찾아서 물어본다. * 그것도 없으면 저자 메일 주소를 알아내서 물어본다. * 저자 메일주소도 없으면 [stackoverflow에 물어본다.](https://stackoverflow.com/search?q=how+to+contribute) --- class: center, middle # 프로젝트에 패치 보내는 방법들 --- ## 그냥 메일 난이도 ★ 개발자에게 메일로 패치파일을 첨부해서 보낸다. * xdebug의 예: https://inbox.google.com/u/0/search/derick%40xdebug.org --- ## 이슈 트래커 난이도 ★★ 1. 이슈트래커에 이슈를 등록하고, 패치파일을 첨부한다. 2. 이슈 댓글을 통해 코드리뷰 진행 3. 업데이트하려면 패치파일을 또 첨부함 * Python의 예: http://bugs.python.org/issue14809 --- ## Github 난이도 ★★★ 1. github 가입 2. 프로젝트 포크 3. 포크한 프로젝트에서 코드를 고치고 push 4. PullRequest 보냄 5. PullRequest 에서 코드리뷰 진행 6. 업데이트하려면 다시 push * Node.js의 예: https://github.com/joyent/node/pull/3057 --- ## Git + gerrit 난이도 ★★★★ 1. gerrit 가입 2. commit-msg hook 설정 3. 로컬에서 코드를 작성하여 Git으로 커밋 4. 작성한 커밋을 gerrit으로 push ``` $ git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master ``` 5. gerrit을 통해 코드리뷰 진행 6. 업데이트하려면 다시 push * JGit의 예: https://git.eclipse.org/r/#/c/31944/ --- ## Git + 메일링 리스트 난이도 ★★★★★★★ ### 보내기 1. 내 PC에서 메일 발송이 가능하도록 sendmail 설치 2. Git이 메일을 보낼 수 있도록 sendmail 설정 3. 로컬에서 코드를 작성하여 Git으로 커밋 4. git-format-patch로 패치를 생성. 패치가 크다면 다음과 같이 커버레터도 만듦 ``` $ git format-patch --cover-letter master..my-patch ``` 5. 커버레터를 생성하게 했다면 만들어진 커버레터 파일을 고쳐서 내용 작성 ``` $ vim 0000-cover-letter.patch ``` 6. 패치를 메일로 발송 ``` $ git send-email *.patch ``` 7. 메일을 통해 코드리뷰 진행 --- ## Git + 메일링 리스트 난이도 ★★★★★★★ ### 업데이트 1. git-format-patch로 패치파일들을 다시 생성 2. 패치파일들의 메일제목을 고쳐서 버전을 올려줌 3. git-send-email로 다시 패치 발송. 1. 이 때 패치 리뷰에 참여한 사람들을 참조로 넣어줌 2. 논의가 진행되는 메일 스레드의 메일 아이디를 In-Reply-To 헤더에 넣어줌. * Git의 예: http://git.661346.n2.nabble.com/PATCH-v4-0-1-http-Add-Accept-Language-header-if-possible-tc7615482.html#none --- ## Git + 메일링 리스트 난이도 ★★★★★★★ ### 너무 어려워서... * 불만: https://github.com/git/git/pull/119 * [토론](./git-merge-2015.png) * 개선: https://github.com/git/git/pull/189 --- # 팁 * 관심있는 소수의 프로젝트에 집중하는 편이 낫다. * 코드 리뷰는 단번에 끝내는 것이 낫다. 손 놓으면 다시 하기 싫어진다. * 커뮤니티 사람들과 친해지면 좋다. 메일 쓰기가 편해진다. --- class: center, middle # QnA ---