이 글에서는 greenplum-db Contributing 안내 문서에 대해서 설명합니다. 이 글을 보시고 greenplum github에 기여해 보세요.
Greenplum은 GitHub의 메인 gpdb 리포지토리에 대한 커밋 권한을 가진 핵심 개발자 팀에 의해 유지 관리됩니다. 동시에 더 넓은 Greenplum 커뮤니티의 모든 분들로부터 기여를 받고자 합니다.
이 섹션에서는 코드 또는 문서 변경 사항이 Greenplum에 추가되고 향후 릴리스에 표시되기를 원하는 경우 알아야 할 모든 사항을 다룹니다.
Getting started
Greenplum은 GitHub에서 개발되며, 기여를 원하는 사람은 누구나 GitHub 계정이 있어야 하고 Git 도구와 워크플로에 익숙해야 합니다. 또한 일부 기여에 대해서는 개발자 메일링 리스트에서 더 자세한 논의가 이루어질 수 있으므로 해당 메일링 리스트를 팔로우하는 것이 좋습니다.
GitHub 계정이 있으면 이 리포지토리를 포크하여 해킹을 시작하고? 풀 리퀘스트의 소스로 사용할 수 있는 비공개 사본을 만드세요.
그린플럼에 기여하는 모든 사람은 기업 또는 개인 기여자 라이선스 계약의 적용을 받아야 합니다. 아직 참여하지 않으셨다면 기여자 라이선스 계약을 작성하여 제출해 주세요. 아주 사소한 변경 사항이라도 명백한 수정 사항에 해당하는 경우 CLA 없이도 기여하실 수 있습니다. 하지만 GitHub 워크플로에서 기본적으로 CLA를 확인하므로 "명백한 수정(obvious fixes.)" 예외를 주장하는 대신 CLA를 제출하는 것이 더 쉬울 수 있습니다.
Contributor License Agreement 하러 가기
Licensing of Greenplum contributions
당신이가 제출하는 기여(수정 소스)가 원본 저작물인 경우, 귀하는 Pivotal이 Apache 라이선스 버전 2.0에 따라 다운스트림 소비자에게 제공되는 전체 Greenplum 릴리스의 일부로 이를 릴리스할 것이라고 가정할 수 있습니다. 그러나 그 외에도, Pivotal은 이를 필요로 하는 업스트림 소비자를 위해 다른 라이선스(예: PostgreSQL 라이선스)로 릴리스하기로 결정할 수도 있습니다. 일반적인 예로, Pivotal이 사용자의 기여를 다시 PostgreSQL 커뮤니티로 업스트림하는 것을 들 수 있습니다(이 작업은 그대로 수행하거나 더 큰 변경 집합의 일부로 사용자의 기여를 업스트림할 수 있습니다).
제출하는 기여물이 독창적인 저작물이 아닌 경우, 라이선스 이름을 명시해야 하며, 또한 해당 라이선스가 Apache License 2.0과 유사한지 확인해야 합니다. 아파치 소프트웨어 재단은 카테고리 A에 이러한 라이선스 목록을 관리합니다. 그 외에도, 이 예시와 비슷한 방식으로 NOTICE 파일에 적절한 저작자 표시를 해야 할 수도 있습니다.
마지막으로, 원본이 아닌 저작물에서 라이선스 헤더를 제거하는 것은 절대로 좋은 생각이 아니라는 점을 명심하세요. 원래 상단에 라이선스 헤더가 있던 파일의 일부를 사용하더라도 라이선스 헤더를 보존하는 편이 좋습니다. 언제나 그렇듯이, 기여한 콘텐츠가 라이선스에 어떤 영향을 미치는지 잘 모르겠다면 개발자 메일링 리스트에서 언제든지 문의해 주세요.
Coding guidelines
피드백을 받고 코드가 프로젝트에 병합되는 것을 볼 수 있는 가능성은 변경 사항이 얼마나 세분화되어 있는지에 따라 크게 달라집니다. 더 큰 변경 사항을 염두에 두고 있다면 코드 작성에 많은 시간을 할애하기 전에 먼저 개발자 메일링 리스트에 참여하여 제안을 공유할 것을 적극 권장합니다. 제안이 커뮤니티의 검증을 받더라도 실제 작업은 일련의 독립적인 소규모 커밋으로 진행하는 것이 좋습니다. 이렇게 하면 검토자의 작업이 훨씬 쉬워지고 피드백의 적시성이 높아집니다.
Greenplum의 C 및 C++ 부분과 관련해서는
PostgreSQL 코딩 규칙을 따르려고 노력합니다. 그 외에도 우리는 아래 내용을 요구합니다:
- All Python code passes Pylint
- All Go code is formatted according to gofmt
변경 사항을 검토할 때 git diff --color를 사용하여 제출하는 코드에 가짜 공백 문제가 발생하지 않도록 하는 것이 좋습니다.
Greenplum에 기여되는 모든 새로운 기능은 함께 기여되는 회귀 테스트(regression tests)를 통해 다루어져야 합니다. 테스트 또는 문서화 방법을 잘 모르시는 경우, gpdb-dev 메일링 리스트에 질문을 올려주시면 개발자 커뮤니티에서 최선을 다해 도와드리겠습니다.
최소한 항상 make installcheck-world를 실행하여 아무것도 깨뜨리지 않았는지 확인해야 합니다.
Changes applicable to upstream PostgreSQL
작업 중인 변경 사항이 PostgreSQL과 Greenplum 간에 공통된 기능에 영향을 미치는 경우, 해당 변경 사항을 PostgreSQL로 포워드 포팅하라는 요청을 받을 수 있습니다. 이는 두 프로젝트 간의 델타(차이점)를 계속 줄이기 위한 것일 뿐만 아니라, PostgreSQL과 관련된 모든 변경 사항이 업스트림 PostgreSQL 커뮤니티의 훨씬 더 광범위한 검토를 통해 이점을 얻을 수 있도록 하기 위한 것입니다. 일반적으로 변경 사항을 포워드 포팅해야 하는지 여부를 확인할 수 있도록 두 코드베이스를 모두 가까이에 두는 것이 좋습니다.
Submission timing
패치나 아이디어에 대한 올바른 논의가 이루어질 확률을 높이려면 커뮤니티 작업 주기에 주의를 기울이세요. 예를 들어, 베타 릴리스 단계에서 새로운 아이디어를 보내주시는 경우 검토를 연기하거나 다음 버전에 포함하도록 할 수 있습니다. Greenplum 릴리스 정책 및 시기에 대해 자세히 알아보려면 메일링 리스트에서 언제든지 문의하세요.
Patch submission
Greenplum 코어 팀 및 다른 Greenplum 커뮤니티와 작업을 공유할 준비가 되면 모든 커밋을 공식 Greenplum에서 포크된 자체 리포지토리의 브랜치에 푸시하고 풀 리퀘스트를 보내야 합니다.
개발 프로세스 초기에 피드백을 받기 위해 진행 중인 작업(Work In Progress)을 제출하는 것도 환영합니다. 풀 리퀘스트를 열 때 PR을 만들 때 드롭다운 메뉴에서 '초안'을 선택하여 풀 리퀘스트의 의도를 명확하게 표시하세요. 제목 앞에 "WIP:"를 붙이는 것도 좋은 방법입니다.
모든 새로운 기능은 메인 브랜치에 대해 제출해야 합니다. 버그 수정도 지원되는 백 브랜치에만 존재하지 않는 한 메인 브랜치에 대해 제출해야 합니다. 버그가 메인 브랜치와 백 브랜치 모두에 존재하는 경우 PR 설명에 이를 설명하세요.
Validation checks and CI
풀 리퀘스트를 제출하면 자동화된 CI 파이프라인에 의해 수행되는 여러 가지 유효성 검사 결과를 즉시 확인할 수 있습니다. 또한 CLA(Contributor License Agreement)가 인식되었는지 여부를 알려주는 CLA 검사도 수행됩니다. 이러한 검사 중 하나라도 실패하면 풀 리퀘스트를 업데이트하여 문제를 처리해야 합니다. 유효성 검사에 실패한 풀 리퀘스트는 커뮤니티 멤버로부터 더 이상 동료 검토를 받을 가능성이 매우 낮습니다.
CLA 검사에 실패하는 가장 일반적인 이유는 파일에 있는 이메일과 풀 리퀘스트의 일부로 제출된 커밋에 기록된 이메일이 일치하지 않는 경우입니다.
특정 유효성 검사에 실패한 이유를 알 수 없는 경우 개발자 메일링 리스트에 문의하되, 이메일에 풀 리퀘스트에 대한 직접 링크를 포함해야 합니다.
Patch review
유효성 검사를 통과하여 제출된 풀리퀘스트는 동료 검토를 받을 수 있는 것으로 간주됩니다. 동료 검토는 Greenplum에 대한 기여가 고품질이며 로드맵 및 커뮤니티 기대치에 잘 부합하는지 확인하는 프로세스입니다. Greenplum 커뮤니티의 모든 구성원은 풀 리퀘스트를 검토하고 피드백을 제공하도록 권장됩니다. 핵심 팀원이 아니어도 참여할 수 있으므로, Greenplum에 장기적으로 기여하는 데 관심이 있는 사람이라면 누구나 풀 리퀘스트를 검토해 볼 것을 권장합니다. Linus의 말처럼"given enough eyeballs, all bugs are shallow(보는 사람이 충분하면 버그는 확률이 낮아진다)"고 할 수 있습니다.
동료 검토의 결과 중 하나는 풀 리퀘스트를 특정 방식으로 수정해야 한다는 의견이 될 수 있습니다. GitHub에서는 풀리퀘스트가 전송된 브랜치에 추가 커밋을 푸시할 수 있습니다. 그러면 모든 리뷰어가 추가 커밋을 볼 수 있습니다.
동료 검토는 참가자들로부터 +1표가 하나 이상이고 -1표가 없을 때 수렴됩니다. 이 시점에서 핵심 팀원 중 한 명이 변경 사항을 프로젝트에 반영할 것으로 확인해야 합니다.
Greenplum은 합의에 기반한 협업 환경이라는 점에 자부심을 가지고 있습니다. 우리는 거부권을 인정하지 않으며, 동료 검토의 일부로 투표한 -1표에는 변경 사항의 문제점에 대한 자세한 기술적 설명이 있어야 합니다. 의견이 강하게 대립하는 경우, 보다 자연스러운 대화가 이루어질 수 있도록 메일링 리스트에 문제를 제기하는 것이 좋습니다.
패치 검토 중 언제든지 검토자 및 핵심 팀원의 가용성에 따라 지연이 발생할 수 있습니다. 조금만 기다려주세요. 그렇다고 해서 낙담하지 마세요. 며칠 동안 예상했던 피드백을 받지 못했다면 풀 리퀘스트 자체에 업데이트를 요청하는 댓글을 추가하거나 메일링 리스트에 이메일을 보내세요.
Direct commits to the repository
간혹 핵심 팀원이 풀 리퀘스트 워크플로우를 거치지 않고 리포지토리에 직접 커밋하는 것을 볼 수 있습니다. 이는 작은 변경 사항에만 적용되며, 테스트 실패를 초래할 수 있는 기능에 변경 사항이 영향을 미치는 경우 풀 리퀘스트 워크플로우를 거쳐야 한다는 것이 저희의 경험 법칙입니다. 반면에 코드 베이스의 비기능적인 부분(예: 주석 내부의 오타 수정)에 변경이 있는 경우 핵심 팀원은 리포지토리에 직접 커밋할 수 있습니다.
Documentation
For Greenplum Database documentation, please check the online documentation.
For further information beyond the scope of this README, please see
our wiki.
Reference
