PostgreSQL CommitFest(CF)

개요

Commit Fest는 주기적으로 하고, PostgreSQL의 새로운 개발을 중지하고 패치(Path)에 대한 리뷰 및 커밋에 중점을 둔다.

Commit Fest Home: https://commitfest.postgresql.org/

 

릴리즈 단계는 알파 릴리즈, 베타 릴리즈, 파이널 릴리즈 순서로 진행된다.

 

Commit까지의 과정은 1) Desirability, 2) Design, 3) Implement, 4) Test, 5) Review, 6) Commit 순서로 진행된다.

1) Desirability & 2) Design

Todo List(https://wiki.postgresql.org/wiki/Todo)에서 작업하고자 하는 아이템을 찾는다.

pgsql-hackers 메일리스트에 무엇을 할지 제안하는 이메일을 보낸다. 작업의 중복이나 요구사항을 잘못 이해했을 경우를 대비해 메일에는 내부 구현 방법과 사용자 측면에서 변화되는 내용 등을 포함해야 한다. 작업의 시작 전에 커뮤니티의 피드백을 얻는게 중요하기 때문이다.

3) Implement

코딩 규칙(https://www.postgresql.org/docs/devel/source.html)을 확인한다.

개발자 FAQ(https://wiki.postgresql.org/wiki/Developer_FAQ)를 확인한다.

4) Test

컴파일과 테스트를 성공해야 한다.

특정 플랫폼에 관련된 부분이 포함되어 있다면 그 플랫폼에서도 테스트되어야 한다.

Regression 테스트를 포함했는지 확인한다.

5) Review & 6) Commit 

3가지 방식이 있다.

첫 번째는 제안자가 pgsql-hackers에 패치를 보내고 커미터가 즉시 커밋하는 경우이다.

두 번째는 제안자가 pgsql-hackers에 패치를 보내고 commitfest queue에 스스로 패치를 추가하여 커미터가 queue에서 패치를 골라 커밋하는 경우이다.

마지막은 pgsql-hackers에 패치를 보내고 Bruce(pgsql-hacker)가 반영되지 않은 패치 리스트에 추가하여 다은 commitfest가 시작되면, Alvaro(commitfest 관리자)가 commitfest queue에 추가한다. 커미터가 queue에서 패치를 선택하여 커밋하는 경우이다.

 

패치 리뷰

• 리뷰시 주의사항

리뷰가 시작되면 5일 내로 최초 리뷰를 전송해야 한다. 리뷰가 일부 밖에 안 됐거나 시간이 더 필요하다는 내용이라도 우선 연락해야 한다. 안 하면 차단 당한다.

리뷰 및 개발에 대한 대화 창구는 pgsql-hackers 메일링 리스트를 통해 되어야 한다.

리뷰에 대한 이메일을 보낼 때 메일 스레딩을 유지해야 한다. 새로 메일 쓰지 말고 그대도 reply하면 된다.

• 리뷰 제출

1) 패치는 context diff 형식인가? diff -c 또는 diff -u 형식을 가져야 한다.

2) get master에 오류 없이 적용할 수 있는가?

3) 적합한 테스트 및 필요한 문서 패치 등이 이루어 졌는가?

 

• 사용성

패치에 실제로 구현되어 있는가?

바라던 것인가?

이미 존재하진 않는가?

SQL 스펙을 따르거나 커뮤니티의 동의를 얻은 동작인가?

pg-dump의 지원을 포함하는가?

위험하지 않는가?

모든 기본사항을 충족하는가?

• 기능 테스트

패치를 적용하고 다음을 테스트한다.

기대한 대로 작동하는가?

패치 제작자가 고려하지 못한 경우가 있는가?

assertion 또는 crash는 없는가?

리뷰는 configure의 --enable-cassert와 --enable-debug 옵션과 함께 수행되어야 한다.

 

• 성능 리뷰

패치가 심플 테스트에서 느리지 않는가?

성능 향상을 주장하는 것이라면 그 주장이 진짜인가?

다른 부분에 성능 저하가 있는가?

 

• 코딩 리뷰

코딩 규칙을 따르고 있는가?

이식에 문제가 없는가?

윈도우와 BSD 등 외에서도 작동하는가?

코드의 주석이 충분하고 정확한가?

주석에서 설명한 대로 동작하는가?

컴파일할 때 경고를 출력하지 않는가?

당신은 crash를 일으킬 수 있는가?

 

• 아키텍처 리뷰

다른 기능이나 모듈과 비교하여 서로 일관성이 있는가?

문제가 될 수 있는 상호의존적인 부분이 있는가?

• 다시 리뷰

리뷰어는 리뷰어로서 해야할 일들을 모두 충족했는가?

 

RRR(Round Robin Reviewer)

commitfest manager에 의해 commitfest 기간 중 무작위로 패치를 할당받는 지원자이다.

패치의 할당은 일반적으로 리뷰의 실력에 따라 배분된다.

실력있는 리뷰어는 일반적으로 좋은 C 기술과 PostgreSQL의 일반적인 지식을 갖고 있는 사람이고, 일부는 숙력된 PostgreSQL 해커이다.

• RRR이 되려면?

pgsql-hackers와 pgsql-rrreviewers 메일링 리스트 구독을 신청한다.

pgsql-rrreviewers에 리뷰 지원으로 신청한다.

wiki.postgresql.org에 가입한다.

reviewing a patch 페이지와 이와 관련된 페이지들과 문서를 보라.

 

• RRR이 되면?

commitfest manager는 이메일을 통해 패치를 할당해줄 것이다.

commitfest.postgresql.org에 방문하여 패치를 수정하고 reviewer로 자신의 이름을 넣는다.

당신이 패치를 리뷰하길 원하지 않거나 못 하겠으면 당신은 24시간 안에 거절해야 한다. 

패치에 대한 정보를 읽고 패치와 관련된 다른 코멘트들을 찾기 위해선 메일링 리스트 아카이브를 검색한다. 당신이 패치와 관련된 스레드를 찾았는데 아직 웹 어플리케이션이 항목에서 참조되지 않았다면 그 스레드의 메시지 ID를 포함하는 코멘트를 추가한다.

패치에 대한 리뷰는 4일간 이루어진다.

-hackers 상의 메일 스레드에 커멘트로 답장한다. 제안자가 참조(CC)돼 있어야 한다.

commitfest.postgresql.org에 패치를 클릭하여 당신의 코멘트에 summary를 입력하고, 리뷰에 대한 commit type을 설정하고, -hackers 메일 리스트 상의 당신의 메시지 ID를 붙여주고, 리뷰의 summary를(한두줄로) 적어둔다.

만약 예비 리뷰가 아니라면 당신은 최대한 빨리 추가적으로 리뷰를 보내야 한다.

당신이 다른 패치를 작업할 준비가 되었다면 commitfestmanager에게 메일을 보낸다.

• 리뷰에 대한 가이드

패치 제안자에게 정중해야 한다. 당신도 아마 언젠가는 그 사람일 수도 있다.

질문이 있으면 pgsql-hackers 메일링 리스트에 올린다.

도움을 요청하는 것을 망설이지 말라. 부족하게 마친 리뷰는 전혀 검토하지 않는 리뷰보다 더 commitfest를 느려지게 만든다.

당신은 커밋터의 작업량을 줄이기 위해 도와주고 있다. 당신이 할 수 있는 만큼 해보고 중지한다.

당신이 리뷰를 완료하지 못하겠거든 바로 commitfest manager에게 연락한다.

메일 아카이브를 읽을 때, 패치에 대한 스레드 전체를 읽도록 한다.

 

• 패치의 상태

진행 상태

needs review: 리뷰를 기다림

waiting on author: 이번 commitfest 동안 다시 제출되기를 기다린다.

discussing review results: 리뷰는 끝났지만 이 패치의 다음단계 명확하지 않다. pgsql-hackers 리스트에서 논의한다.

ready for committer: 리뷰는 끝났고, 리뷰어에 의해 이슈를 찾을 수 없고, 커밋터에 의한 최종 리뷰를 준비한다.

 

최종 상태

returned with feedback: 제출했다면 다음 commitfest의 새로운 버전에서 리뷰할 것이다.

rejected: 원하지 않는다.

committed: 커밋터에 의해 적용되었고, 이슈로 남아있지 않는다.

 

추가사항

PostgreSQL on FreeNode(https://www.postgresql.org/community/irc/)

사용자 및 개발자들과 채팅할 수 있다.

 

peg(https://github.com/gregs1104/peg)

PG 빌드 환경을 간소화한다.