src/main/asciidoc/_chapters/community.adoc - hbase - Git at Google

 ////
 /**
  *
  * Licensed to the Apache Software Foundation (ASF) under one
  * or more contributor license agreements.  See the NOTICE file
  * distributed with this work for additional information
  * regarding copyright ownership.  The ASF licenses this file
  * to you under the Apache License, Version 2.0 (the
  * "License"); you may not use this file except in compliance
  * with the License.  You may obtain a copy of the License at
  *
  *     http://www.apache.org/licenses/LICENSE-2.0
  *
  * Unless required by applicable law or agreed to in writing, software
  * distributed under the License is distributed on an "AS IS" BASIS,
  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  * See the License for the specific language governing permissions and
  * limitations under the License.
  */
 ////

 [[community]]
 = Community
 :doctype: book
 :numbered:
 :toc: left
 :icons: font
 :experimental:

 == Decisions

 .Feature Branches

 Feature Branches are easy to make.
 You do not have to be a committer to make one.
 Just request the name of your branch be added to JIRA up on the developer's mailing list and a committer will add it for you.
 Thereafter you can file issues against your feature branch in Apache HBase JIRA.
 Your code you keep elsewhere -- it should be public so it can be observed -- and you can update dev mailing list on progress.
 When the feature is ready for commit, 3 +1s from committers will get your feature merged.
 See link:https://lists.apache.org/thread.html/200513c7e7e4df23c8b9134eeee009d61205c79314e77f222d396006%401346870308%40%3Cdev.hbase.apache.org%3E[HBase, mail # dev - Thoughts
               about large feature dev branches]

 [[hbase.fix.version.in.jira]]
 .How to set fix version in JIRA on issue resolve

 Here is how we agreed to set versions in JIRA when we
 resolve an issue. If master is going to be 3.0.0, branch-2 will be 2.4.0, and branch-1 will be
 1.7.0 then:

 * Commit only to master (i.e., backward-incompatible new feature): Mark with 3.0.0
 * Commit only to master and branch-2 (i.e., backward-compatible new feature, applicable only to
   2.x+): Mark with 3.0.0 and 2.4.0
 * Commit to master, branch-2, and branch-1 (i.e., backward-compatible new feature, applicable
   everywhere): Mark with 3.0.0, 2.4.0, and 1.7.0
 * Commit to master, branch-2, and branch-2.3, branch-1, branch-1.4 (i.e., bug fix
   applicable to all active release lines): Mark with 3.0.0, 2.4.0, 2.3.x, 1.7.0, and 1.4.x
 * Commit a fix to the website: no version

 [[hbase.when.to.close.jira]]
 .Policy on when to set a RESOLVED JIRA as CLOSED

 We agreed that for issues that list multiple releases in their _Fix Version/s_ field, CLOSE the issue on the release of any of the versions listed; subsequent change to the issue must happen in a new JIRA.

 [[no.permanent.state.in.zk]]
 .Only transient state in ZooKeeper!

 You should be able to kill the data in zookeeper and hbase should ride over it recreating the zk content as it goes.
 This is an old adage around these parts.
 We just made note of it now.
 We also are currently in violation of this basic tenet -- replication at least keeps permanent state in zk -- but we are working to undo this breaking of a golden rule.

 [[community.roles]]
 == Community Roles

 === Release Managers

 Each maintained release branch has a release manager, who volunteers to coordinate new features and bug fixes are backported to that release.
 The release managers are link:https://hbase.apache.org/team-list.html[committers].
 If you would like your feature or bug fix to be included in a given release, communicate with that release manager.
 If this list goes out of date or you can't reach the listed person, reach out to someone else on the list.


 .Release Managers
 [cols="1,1,1,1", options="header"]
 |===
 | 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
 | Check the https://hbase.apache.org/downloads.html[download] page
 | *NOT YET*

 |===

 [[hbase.commit.msg.format]]
 == Commit Message format

 We agreed to the following Git commit message format:
 [source]
 ----
 HBASE-xxxxx <title>. (<contributor>)
 ----
 If the person making the commit is the contributor, leave off the '(<contributor>)' element.
	////
	/**
	*
	* Licensed to the Apache Software Foundation (ASF) under one
	* or more contributor license agreements. See the NOTICE file
	* distributed with this work for additional information
	* regarding copyright ownership. The ASF licenses this file
	* to you under the Apache License, Version 2.0 (the
	* "License"); you may not use this file except in compliance
	* with the License. You may obtain a copy of the License at
	*
	* http://www.apache.org/licenses/LICENSE-2.0
	*
	* Unless required by applicable law or agreed to in writing, software
	* distributed under the License is distributed on an "AS IS" BASIS,
	* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
	* See the License for the specific language governing permissions and
	* limitations under the License.
	*/
	////

	[[community]]
	= Community
	:doctype: book
	:numbered:
	:toc: left
	:icons: font
	:experimental:

	== Decisions

	.Feature Branches

	Feature Branches are easy to make.
	You do not have to be a committer to make one.
	Just request the name of your branch be added to JIRA up on the developer's mailing list and a committer will add it for you.
	Thereafter you can file issues against your feature branch in Apache HBase JIRA.
	Your code you keep elsewhere -- it should be public so it can be observed -- and you can update dev mailing list on progress.
	When the feature is ready for commit, 3 +1s from committers will get your feature merged.
	See link:https://lists.apache.org/thread.html/200513c7e7e4df23c8b9134eeee009d61205c79314e77f222d396006%401346870308%40%3Cdev.hbase.apache.org%3E[HBase, mail # dev - Thoughts
	about large feature dev branches]

	[[hbase.fix.version.in.jira]]
	.How to set fix version in JIRA on issue resolve

	Here is how we agreed to set versions in JIRA when we
	resolve an issue. If master is going to be 3.0.0, branch-2 will be 2.4.0, and branch-1 will be
	1.7.0 then:

	* Commit only to master (i.e., backward-incompatible new feature): Mark with 3.0.0
	* Commit only to master and branch-2 (i.e., backward-compatible new feature, applicable only to
	2.x+): Mark with 3.0.0 and 2.4.0
	* Commit to master, branch-2, and branch-1 (i.e., backward-compatible new feature, applicable
	everywhere): Mark with 3.0.0, 2.4.0, and 1.7.0
	* Commit to master, branch-2, and branch-2.3, branch-1, branch-1.4 (i.e., bug fix
	applicable to all active release lines): Mark with 3.0.0, 2.4.0, 2.3.x, 1.7.0, and 1.4.x
	* Commit a fix to the website: no version

	[[hbase.when.to.close.jira]]
	.Policy on when to set a RESOLVED JIRA as CLOSED

	We agreed that for issues that list multiple releases in their _Fix Version/s_ field, CLOSE the issue on the release of any of the versions listed; subsequent change to the issue must happen in a new JIRA.

	[[no.permanent.state.in.zk]]
	.Only transient state in ZooKeeper!

	You should be able to kill the data in zookeeper and hbase should ride over it recreating the zk content as it goes.
	This is an old adage around these parts.
	We just made note of it now.
	We also are currently in violation of this basic tenet -- replication at least keeps permanent state in zk -- but we are working to undo this breaking of a golden rule.

	[[community.roles]]
	== Community Roles

	=== Release Managers

	Each maintained release branch has a release manager, who volunteers to coordinate new features and bug fixes are backported to that release.
	The release managers are link:https://hbase.apache.org/team-list.html[committers].
	If you would like your feature or bug fix to be included in a given release, communicate with that release manager.
	If this list goes out of date or you can't reach the listed person, reach out to someone else on the list.


	.Release Managers
	[cols="1,1,1,1", options="header"]
	\|===
	\| 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
	\| Check the https://hbase.apache.org/downloads.html[download] page
	\| NOT YET

	\|===

	[[hbase.commit.msg.format]]
	== Commit Message format

	We agreed to the following Git commit message format:
	[source]
	----
	HBASE-xxxxx <title>. (<contributor>)
	----
	If the person making the commit is the contributor, leave off the '(<contributor>)' element.