Erlang/OTP에 기여하기

1. 라이선스
2. 버그 보고
3. 풀 리퀘스트 제출
   1. 버그 수정 1.
   2. [새로운 기능 추가](#새로운 기능 추가)
   3. 풀 리퀘스트 제출하기 전
   4. 풀 리퀘스트를 제출한 후 4.

라이선스

본인은 이 프로젝트에 기여함으로써 다음을 증명합니다:

(a) 기여의 전부 또는 일부를 본인이 직접 작성했으며, 본인은
    오픈소스 라이선스에 따라 제출할 권리가 있습니다.
    또는

(b) 기여는 이전 작업을 기반으로 하며, 내가 알고 있는 한 
    내가 아는 한, 적절한 오픈 소스 라이선스에 따라 보장됩니다. 
    소스 라이선스 및 해당 라이선스에 따라 다음과 같은 권리가 있습니다.   
    해당 저작물의 전체 또는 일부를 수정하여 제출할 권리가 있으며
    또는 동일한 오픈 소스 라이선스에 따라 제가 일부 또는 전체를 수정하여 제출할 권리가 있습니다.
    다른 라이선스에 따라 제출할 수 있는 경우 제외), 다음과 같은 경우 
    파일에 표시된 경우; 또는

(c) 기여는 다른 사람에 의해 직접 제공되었습니다.
    (가), (나) 또는 (다)를 인증한 사람에 의해 직접 제공되었으며 내가 수정하지 않은 경우
    수정하지 않았습니다.

(d) 본인은 이 프로젝트와 기여가 공개되어 있으며
    공개되며 기여에 대한 기록( 
    내 서명을 포함하여 내가 제출한 모든 개인 정보)
    서명)는 무기한 유지되며 이 프로젝트 또는 오픈소스에 따라
    이 프로젝트 또는 관련된 오픈소스 라이선스와 일관되게
    에 따라 재배포될 수 있음을 동의합니다.

개발자 원산지 증명서 라이선스 사본은 http://developercertificate.org/ 을 참조하세요.

Erlang/OTP는 Apache License 2.0에 따라 라이센스가 부여됩니다: LICENSE.txt

버그 보고하기

https://github.com/erlang/otp/issues 에서 버그를 신고하세요. 자세한 내용은 버그 리포트를 참조하세요.

풀 리퀘스트 제출하기

풀 리퀘스트를 개설하여 Erlang/OTP에 기여할 수 있습니다.

'깃 체크아웃 -b new-branch-name'을 사용하여 풀 리퀘스트를 위한 새 브랜치를 생성하세요. 브랜치에 stdlib/lists-length-fix와 같이 짧지만 설명이 포함된 이름을 지정하세요. 유지또는마스터`에서 직접 작업을 수행하지 마세요.

버그 수정하기

• 대부분의 경우 버그 수정을 위한 풀 리퀘스트는 maint 브랜치를 기반으로 해야 한다. 마스터 브랜치에 도입된 버그에 대한 수정과 같은 예외가 있습니다.

• 버그가 수정되었는지 **그리고 수정된 상태로 유지되는지 확인하기 위해 테스트 케이스를 포함하세요.

• 팁: 버그를 수정하기 전에 테스트 케이스를 작성하여 버그를 잡았는지 확인할 수 있도록 하세요.

• git 리포지토리에 테스트 스위트가 없는 애플리케이션의 경우, 커밋 메시지 또는 작은 코드 샘플을 커밋 메시지에 제공하거나 오류를 유발하는 모듈을 이메일로 보내주시면 감사하겠습니다.

새 기능 추가

• 대부분의 경우 새로운 기능에 대한 풀 리퀘스트는 master 브랜치를 기반으로 해야 한다.

• 새로운 기능에 대한 논의는 erlang 포럼에서 하는 것을 권장합니다, 특히 주요한 신규 기능이나 ERTS, 커널, STDLIB의 새로운 기능에 대해서는 더욱 그렇습니다.

• 해당 기능이 왜 필요한지 설명하는 좋은 커밋 메시지를 작성하는 것이 중요합니다. 2년 후에도 특정 기능이 왜 필요한지 알고 싶어하는 사람이 있다면 2년 후에도 특정 기능이 왜 필요한지 쉽게 알 수 있습니다. 풀리퀘스트에 풀 리퀘스트에 동일한 정보를 제공하는 것은 아무런 해가 되지 않습니다(풀 리퀘스트가 단일 커밋으로 구성된 경우, 커밋 메시지가 자동으로 풀리퀘스트에 추가된다).

• 몇 가지 예외를 제외하고는 기능을 테스트하는 새로운 테스트 케이스를 작성하는 것이 필수입니다. 테스트 케이스는 나중에 기능이 작동을 멈추지 않는지 확인하기 위해 필요합니다.

• 해당 기능을 설명하기 위해 문서를 업데이트합니다.

• 새 기능이 모든 주요 플랫폼에서 빌드되고 작동하는지 확인합니다. 예외는 일부 플랫폼에서만 일부 플랫폼에서만 의미가 있는 기능(예: Windows 레지스트리에 액세스하기 위한 win32reg 모듈)은 예외입니다.

• 기능이 이전 버전과의 호환성을 깨뜨리지 않는지 확인하세요. 일반적으로 이전 버전과의 호환성은 이전 버전과의 호환성을 깨는 것은 매우 타당한 이유가 있을 때만 가능합니다. 보통은 릴리스 한두 번 전에 기능을 먼저 사용 중단합니다.

• 일반적으로 언어 변경/확장에는 EEP(Erlang 개선 제안서)를 작성하고 승인을 받아야 합니다. 승인을 받아야 OTP에 포함될 수 있습니다. ERTS, 커널 또는 STDLIB의 주요 변경 사항이나 새로운 기능은 EEP가 필요하거나 최소한 메일링 리스트에서 메일링 리스트에서 토론이 필요합니다.

풀 리퀘스트를 제출하기 전에 ###

• 기존 테스트 케이스가 실패하지 않았는지 확인하세요. 모든 테스트를 실행할 필요는 없습니다(많은 시간이 소요될 수 있음), 최소한 변경한 애플리케이션에 대한 테스트는 실행해야 합니다.
• 문서가 빌드되고 dtd에 따라 작성되었는지 확인합니다(예: make xmllint 또는 cd lib/stdlib/ && make xmllint).
• 새로운 투석기 경고가 추가되지 않았는지 확인합니다. 예: make dialyzer 또는 cd lib/stdlib/ && make dialyzer
• https://github.com/$YOUR_GITHUB_USER/otp/actions로 이동하여 otp 포크에 대한 github 액션 빌드를 활성화할 수 있는지 확인합니다.

테스트](https://github.com/erlang/otp/blob/master/HOWTO/TESTING.md) 및 개발 하우투 에서 실행 테스트 사용 방법과 Erlang/OTP 메이크 시스템 사용 방법을 자세히 알아보세요.

브랜치에 깨끗한 커밋이 포함되어 있는지 확인하세요:

• 커밋 메시지의 첫 줄을 72자보다 길게 만들지 마세요. **첫 줄을 마침표로 끝내지 마세요.

• 좋은 커밋 메시지 작성하기](https://github.com/erlang/otp/wiki/Writing-good-commit-messages) 가이드라인을 따르세요.

• 브랜치에 maint 또는 master를 병합하지 마세요. Merge 충돌을 해결해야 하거나 충돌을 해결하거나 최신 변경사항을 포함해야 하는 경우 git rebase를 사용한다.

• 각 커밋은 기능 추가 또는 버그 수정과 같은 논리적 변경 사항을 나타내야 하며 문서 및 테스트에 대한 관련 변경 사항도 포함해야 한다.

• 각 커밋은 개별적으로 컴파일하고 가장 관련성이 높은 테스트 케이스를 통과해야 합니다. 이렇게 하면 강력한 git bisect 명령을 사용할 수 있습니다.

• 여러 애플리케이션에 대한 변경 사항은 코드 검토를 용이하게 하기 위해 별도의 커밋에서 수행해야 하며, 깔끔한 빌드 기능을 방해하지 않는 등 특별한 상황이 아니라면 단일 커밋으로 수행해야 한다.

• 커밋하기 전에 git diff --check로 불필요한 공백이 있는지 확인하세요. 단, 변경하지 않은 소스 줄에 있는 기존 공백 오류는 수정하지 마세요.

코딩 스타일을 확인하세요:

• 변경 내용이 변경 내용을 둘러싼 코드의 코딩 및 들여쓰기 스타일을 따르는지 확인하세요.

• 주석 처리된 코드나 더 이상 필요하지 않은 파일은 커밋하지 마세요. 해당 코드 또는 파일을 제거하세요.

• 대부분의 코드(Erlang 및 C)에서 들여쓰기는 4단계입니다. 공백만 사용한 들여쓰기는 강력히 권장합니다.

Emacs 구성하기

Emacs를 사용하는 경우 Erlang 모드를 사용하고 '.emacs'에 다음 줄을 추가합니다:

(setq-default 들여쓰기-탭-모드 nil)
(setq c-basic-offset 4)

Erlang 모드에 대해서만 설정을 변경하려면 다음과 같은 후크를 사용할 수 있습니다:

(add-hook 'erlang-mode-hook 'my-erlang-hook)

(defun my-erlang-hook ()
  (setq 들여쓰기-탭-모드 nil))

풀 리퀘스트를 제출한 후

• 풀 리퀘스트에 대한 토론을 따르고, 질문에 답변하고, 검토자가 요청한 변경 사항을 변경 사항을 구현하세요. 작은 변경사항은 관련된 커밋으로 압축해야 합니다.

• 풀리퀘스트에 새로운 공개 기능을 도입하는 경우, 풀리퀘스트에 태그를 지정해야 합니다. 태그가 있어야 하며, 이 태그는 함수 문서의 '이후' 태그에 표시되어야 합니다. 일반적으로 PR이 병합되는 시점에는 아직 확실하지 않으므로, 풀리퀘스트에 할당된 사람이 풀 리퀘스트에 할당된 사람이 내부 티켓 번호(예: OTP-12345)를 제공해야 합니다. 이후태그의 자리 표시자로 사용할 내부 티켓 번호(예:since="OTP @OTP-12345@`)를 제공해야 합니다. 새로운 함수가 OTP 릴리스와 함께 릴리스되면 이 자리 표시자가 실제 OTP 버전으로 대체되어 "OTP 26.0"과 같이 됩니다.