HBase 커뮤니티
HBase 커뮤니티 (Community)
Apache HBase 개발 커뮤니티가 어떻게 함께 작업하는지에 대한 규칙과 역할을 정리한 페이지예요. 컨트리뷰터로서 개발 흐름에 참여할 때 알아 두면 좋아요.
출처: 문서
본문
결정 사항 (Decisions)
기능 브랜치 (Feature Branches)
Feature Branch는 만들기 쉬워요. 커미터가 아니어도 만들 수 있어요. 개발자 메일링 리스트에서 브랜치 이름을 JIRA에 추가해 달라고 요청하면 커미터가 추가해 줘요. 그 후에는 Apache HBase JIRA의 기능 브랜치에 이슈를 등록할 수 있어요. 코드는 다른 곳에 보관하고 — 관찰될 수 있도록 공개 상태로 — dev 메일링 리스트에 진행 상황을 알리면 돼요. 기능이 커밋될 준비가 되면 커미터 3명의 +1을 받으면 기능이 merge돼요. 참고: HBase, mail # dev - Thoughts about large feature dev branches
이슈 해결 시 JIRA의 fix version 설정 방법 (How to set fix version in JIRA on issue resolve)
이슈를 해결할 때 JIRA에서 버전을 설정하는 방법에 대해 우리가 합의한 규칙이에요. master가 3.0.0, branch-2가 2.4.0, branch-1이 1.7.0이 될 예정이라면:
- master에만 커밋(즉, 하위 호환이 안 되는 새 기능): 3.0.0으로 표시
- master와 branch-2에만 커밋(즉, 2.x+에만 적용되는 하위 호환 새 기능): 3.0.0과 2.4.0으로 표시
- master, branch-2, branch-1에 커밋(즉, 어디서나 적용되는 하위 호환 새 기능): 3.0.0, 2.4.0, 1.7.0으로 표시
- master, branch-2, branch-2.3, branch-1, branch-1.4에 커밋(즉, 모든 활성 릴리스 라인에 적용되는 버그 수정): 3.0.0, 2.4.0, 2.3.x, 1.7.0, 1.4.x로 표시
- 웹사이트 수정 커밋: 버전 없음
RESOLVED JIRA를 CLOSED로 바꾸는 시점 정책 (Policy on when to set a RESOLVED JIRA as CLOSED)
Fix Version/s 필드에 여러 릴리스를 나열한 이슈의 경우, 나열된 버전 중 하나가 릴리스되면 이슈를 CLOSE하기로 합의했어요. 이후의 변경은 새 JIRA에서 처리해야 해요.
ZooKeeper에는 transient 상태만! (Only transient state in ZooKeeper!)
zookeeper의 데이터를 죽여도 HBase는 그 위를 타고 넘어가며 zk 콘텐츠를 재생성할 수 있어야 해요. 이 주변에서 오래된 격언이에요. 우리도 방금 그것을 기록했어요. 우리는 현재 이 기본 원칙을 위반하고 있어요 — 적어도 replicat이 zk에 영구 상태를 유지하고요 — 하지만 이 황금률을 깨는 것을 되돌리기 위해 노력 중이에요.
커뮤니티 역할 (Community Roles)
릴리스 매니저 (Release Managers)
유지보수되는 각 릴리스 브랜치에는 릴리스 매니저가 있어요. 그는 새 기능과 버그 수정이 그 릴리스로 백포트되도록 조율하는 자원봉사자예요. 릴리스 매니저는 커미터예요. 특정 릴리스에 자신의 기능이나 버그 수정을 포함시키고 싶다면 그 릴리스 매니저와 소통하세요. 이 목록이 최신이 아니거나 나열된 사람에게 연락할 수 없다면 목록의 다른 사람에게 연락하세요.
릴리스 매니저:
| Release | Release Manager | Latest Release | EOL |
|---|---|---|---|
| 0.94 | Lars Hofhansl | 0.94.27 | April 2017 |
| 0.96 | Michael Stack | 0.96.2 | September 2014 |
| 0.98 | Andrew Purtell | 0.98.24 | April 2017 |
| 1.0 | Enis Soztutar | 1.0.3 | January 2016 |
| 1.1 | Nick Dimiduk | 1.1.13 | December 2017 |
| 1.2 | Sean Busbey | 1.2.12 | June 2019 |
| 1.3 | Mikhail Antonov | 1.3.6 | August 2020 |
| 1.4 | Andrew Purtell | 1.4.14 | October 2021 |
| 1.5 | Andrew Purtell | 1.5.0 | October 2019 |
| 1.6 | Andrew Purtell | 1.6.0 | February 2020 |
| 1.7 | Reid Chan | 1.7.2 | August 2022 |
| 2.0 | Michael Stack | 2.0.6 | September 2019 |
| 2.1 | Duo Zhang | 2.1.10 | May 2020 |
| 2.2 | Guanghao Zhang | 2.2.7 | April 2021 |
| 2.3 | Nick Dimiduk | 2.3.7 | October 2021 |
| 2.4 | Andrew Purtell | 2.4.18 | June 2024 |
| 2.5 | Andrew Purtell | Check the download page | NOT YET |
| 2.6 | Bryan Beaudreault | Check the download page | NOT YET |
커밋 메시지 형식 (Commit Message format)
다음과 같은 Git 커밋 메시지 형식에 합의했어요.
HBASE-xxxxx
커밋을 하는 사람이 기여자(contributor)라면 '(