컨트리뷰션

오픈 소스 소프트웨어 의 묘미 중 하나로, 자체 개발에 참여할 수 있습니다. 이 장에서는 Ryu 의 개발에 참여하는 방법을 소개 합니다.

개발 체제

Ryu 의 개발은 메일링리스트를 중심으로 진행되고 있습니다. 우선은 메일링리스트에 가입 하는 것부터 시작합니다.

https://lists.sourceforge.net/lists/listinfo/ryu-devel

메일링리스트의 교환은 기본적으로 영어로 진행 됩니다. 사용법 등 의문이 있거나 결함으로 보이는 것과 같은 상황에 마주쳤을 때, 이메일을 보내는 것을 망설일 필요는 없습니다. 오픈 소스 소프트웨어를 사용하는 것 자체가 프로젝트에 중요한 기여이기 때문입니다.

개발 환경

이 섹션에서는 Ryu 의 개발에 필요한 환경 및 고려 사항에 대해 설명 합니다.

Python

Ryu 는 Python 2.6 이상을 지원 합니다. 즉, Python 2.7 에서만 사용 가능한 구문 등은 사용하지 마십시오.

Python 3.0 이상 은 당분간 지원 되지 않습니다. 하지만 소스 코드는 향후 변경이 가능한 적게 되도록 작성함을 유의하면 좋을 것입니다.

코딩 스타일

Ryu 소스 코드는 PEP8 코딩 스타일 을 준수하고 있습니다. 뒤에 서술하겠지만, 패치를 보낼 때에는 해당 내용이 PEP8을 준수하고 있는지 미리 확인 하십시오.

http://www.python.org/dev/peps/pep-0008/

또한, 소스 코드가 PEP8을 준수 하는지 확인하려면 테스트 섹션에서 소개하는 스크립트와 함께 검사기를 이용할 수 있습니다.

https://pypi.python.org/pypi/pep8

테스트

Ryu 에는 몇 가지 자동화된 테스트가 있지만 가장 간단하고 많이 사용되는 것은 Ryu 만으로 완성되는 단위 테스트 입니다. 뒤에 이야기하는, 패치를 보낼 때에는 변경 사항 때문에 단위 테스트 실행이 실패하지 않는 것을 미리 확인 하십시오. 또한 새로 추가된 소스 코드에는 단위 테스트에 대해 가능한 많이 설명하는 것이 바람직할 것 입니다.

$ cd ryu/
$ ./run_tests.sh

패치 쓰기

기능 추가 및 버그 수정 등으로 저장소의 소스 코드를 변경 하는 때에는 변경 사항을 패치한 후 , 메일링 리스트로 보냅니다. 큰 변경은 미리 메일링리스트 에서 논의되는 것이 바람직할 것입니다.

주석

Ryu 소스 코드 저장소는 GitHub 에 존재하지만 , 풀 요청을 이용한 개발 프로세스가 아님에 주의 하십시오.

보내는 패치 형식은 Linux 커널 개발 에서 사용되는 스타일을 사용하고 있습니다. 이 섹션에서는 이 스타일 패치를 메일링리스트에 쓰기까지 의 예를 소개 하고 있습니다. 더 자세한 내용은 관련 문서를 참조 하십시오.

http://lxr.linux.no/linux/Documentation/SubmittingPatches

그럼 단계를 소개 합니다.

  1. 소스 코드 를 체크 아웃

우선 Ryu 의 소스 코드 를 체크 아웃 합니다. GitHub 에서 소스 코드 를 fork 하여 자신 의 작업 저장소를 만들어도 상관없지만, 단순화하기 위해 원본을 그대로 사용하여 예제로 설명합니다.

$ git clone https://github.com/osrg/ryu.git $ cd ryu/
  1. 소스 코드 변경

Ryu 소스 코드에 필요한 사항을 변경합니다. 작업을 구분할 때는 변경 내용을 커밋 합시다.

$ git commit -a
  1. 패치 만들기

변경 내용의 변화에 대해 패치를 만듭니다. 패치는 Signed-off-by : 행을 붙이는 것을 잊지 마십시오. 이 서명은 당신이 제출 한 패치가 오픈 소스 소프트웨어 라이선스에 문제가 없음을 선언 합니다.

$ git format-patch origin -s
  1. 패치 쓰기

완성 된 패치 내용이 올바른지 확인한 후 , 메일로 보냅니다. 직접 메일을 보낼 수도 있지만 git-send-email ( 1 ) 을 사용하는 것으로 대화식으로 처리 할 수 있습니다.

$ git send-email 0001-sample.patch
  1. 응답 대기
패치에 대한 응답을 기다립니다. 그대로 받아 들여지는 경우도 있지만, 지적 사항 등이 있으면 내용을 수정하여 다시 보낼 필요가 있을 것입니다.

목차

이전 항목

아키텍처

다음 항목

도입 사례

현재 문서