�ݺ�ߣ

Copyright © 2015 kt NexR. All rights reserved.
1
How to contribute to OSS
박서은
(seoeun25@gmail.com)

2
Agenda
• How to choose OSS
• Issue tracking
• Contribute
• 오픈 소스 참여 체험기
• 주의사항

3
How to choose OSS
• Open Source Software, 그 중에서도 Hadoop Ecosystem 에 관심이
있습니다. 무엇을 해야 할까요.
Image source : Hadoop Essentials, 여기에 없는 프로젝트도 다수

4
How to choose OSS
• 관심 있는 프로젝트
– 평소에 해보고 싶었거나 내부가 궁금한 프로젝트
– 어떤 기능이 있는 지, 앞으로 무엇을 할 지 궁금한 프로젝트
• Community 가 활발한 프로젝트
– 참여자가 많은 프로젝트
– 이슈가 많은 프로젝트
– Trendy 한 프로젝트
• 업무와 연관 된 프로젝트
• 재미가 있는 프로젝트

5
Issue tracking
• Mailing list 가입
– User mailing list
• 주로 사용자 모임 mailing list로 이거 쓰다가 뭐가 안되요, 뭐는 어떻게 해야
하나요, 이상해요…… 같은 메일이 오고 간다.
• 그러다가 contributor, committer가 bug 입니다, 하면서 issue로 등록하는 경
우도 종종 발생
– Dev mailing list
• 프로젝트 개발자 mailing list로 실제 patch나 proposal 을 올리고 feedback
이 오가는 메일 쓰레드
– Review board 가입
• Patch에 대한 리뷰
• 코드, document 등 모든 patch 에 대한 리뷰
• 처음 프로젝트에 접근할 때는 user mailing list에 먼저 가입하고 점
점 관심이 높아 지면 dev list에도 가입할 것을 권장. 안그러면 메일
폭탄을 맞을 수가 있다.

6
Issue tracking
• Issue tracker search
– Mailing list는 가입 이후에 발생되는 이슈에 대해서만 메일을 받을 수
있다.
– 직접 issue tracker에 들어가서 현재 등록된 이슈가 무엇인지, 이번 버전
에서 무얼 개발하고 있는 지 등을 전체적으로 살펴 볼 수 있다.

7
• Download source from git
• Build
– 코드 개발을 하려면 build 는 필수 사항
• 기여대상
– 문서화 : 영어가 되면 도전 (저는 안됩니다)
– Bug fix
– Improvement
– New feature

8
• Patch 적용 cycle
– Issue 생성 (기존에 있는 이슈라면 생략)
– Assignee 가 없는 issue 에만 patch를 올릴 수 있다. (이동네 기본 예절)
– Develop and test > create patch
• code에는 반드시 Unit test 가 포함되어야 한다
• end to end test (manual test)
• 한 번에 patch가 적용되는 경우는 거의 없으므로 patch에 numbering
– Upload patch > patch available
– Review board 등록 (간단한 patch는 생략가능)
– Build with patch
• Patch 가 업로드 되면 project 내부의 build farm에서 자동으로 patch 를 적용하여
build를 하고 결과가 report 된다.
– Build report
• Patch 적용 불가 : 항상 최신 branch를 기반으로 rebase 해서 upload
• Test fail
– Side effect로 새로운 patch 때문에 다른 test 가 fail 될 수 있다. 이런경우를 피하기 위
해 미리 full test를 해서 올려야 한다.
– Side effect도 아닌데 그냥 다른 test가 fail 될 수 있다. 이런 경우, 새로운 patch가 영향
을 주지 않았다는 것을 명시하거나 증명해야 한다.
• Test pass

9
• Patch 적용 cycle
– Committer 가 code review
• Code review 를 잘 해주지 않는다.
• Review please 를 외쳐도 잘 해주지 않는다.
• 영원히 review 없는 patch 도 수두룩하다.
• Issue에 대한 comment만 할 뿐 review 해주지 않는다.
– Code review 의 comment 를 적용하여 다시 patch upload
• 지난번 review 해준 committer가 다시 review 해 주지 않을 때도 있다.
• patch > test > review 의 사이클을 ship it 받을 때 까지 반복
– Ship it
• Committer 가 ship it 하고, snapshot branch 에 commit 해 준다.
• 다음 버전 release 에 볼 수 있다.
– Commit이 되면 committer가 해당 개발자를 contributor list에 넣어주
고, contributor는 issue에 대해서 self assign 이 가능해 진다.

10
오픈소스 개발 체험기
• 대상 project : oozie
• 첫 번째 patch upload
– 2013년 12월 11일 : OOZIE-1638
– 2014년 01월 14일 거의 1 개월 후 첫 comment 등장
– 2015년 02월 19일 1년이 지나도 comment 만 등장
– 여러 committer 들이 comment 하면서 자기들 끼리 관련된 다른 이슈
에 대해서 논의, 그러나 discuss로 끝나고 그냥 여전히 issue로 남음
• 첫 번째 commit
– OOZIE-1846
– 2014년 06월 12일 patch.1 upload
– 2014년 07월 24일 commit
– Contributor list에 등록

11
오픈소스 개발 체험기
• Oozie-4.2 version 140 release log 중 7 개 기여
Contributor Count
yahoo 64
cloudera 37
inmobi 12
livedotcom 9
nexr 7
hortonworks 6
etc 5
46%
26%
9%
6%
5%
4%4%
yahoo clodera inmobi livedotcom nexr hortonworks etc

12
주의사항
• 개발 레벨까지 참여할 필요는 없다.
– Issue 를 계속 tracking 하고 관심을 가지는 게 중요하다.
– 개발은 follow up 하는 여러가지 실천 중에 하나일 뿐이다.
• 여유로운 맨탈이 필요하다
– Patch를 올린다고 해서 review 해주지 않는다. Feedback이 없어도 계속 참여하면 언젠
가는 review 해 준다.
– 처음 진입 장벽이 높은 편이라 쉽게 commit 되지 않는다. 그래도 실망하지 않는다. 전
투력만 떨어진다.
– 저의 경우, 처음 patch 올린 후 7개월만에 commit 되었습니다. (case 마다 다릅니다)
• 꾸준함과 인내력, 그리고 시간이 필요하다
– 꾸준히 follow up 하는 게 좋다.
– 저의 경우, 이번 해는 다른 업무로 바빠서 follow up 하지 못하는 상태입니다만…다시
시작 해야겠지요.
• 쉬운 것 부터 시작한다
– Critical issue는 committer들이 한다. 어차피 처음 보는 이에게는 assign 하지도 않는
다.
– 이들도 community 활성화를 위해서 쉬운 이슈는 newbie라는 태그를 달아놓고
assignee를 비워두고 있다.
– Fix typo 같은 것도 좋다. (다만, 영어다)
• Project 선택도 중요하다
– 활성화된 프로젝트는 많은 사람들이 참여하기 때문에 feedback이 빠르고 할 것도 많
다. (oozie 는 이것과는 좀 거리가 있음)

13
Q&A

�ݺ�ߣ

How to contribute to open source

More Related Content

How to contribute to open source