社区

198.决定

功能分支

功能分支很容易制作。你不必成为一个提交者。只需要在开发人员的邮件列表中将您的分支名称添加到 JIRA，并且提交者将为您添加它。此后，您可以针对 Apache HBase JIRA 中的功能分支提出问题。您保存在其他地方的代码 - 它应该是公共的，以便可以观察到 - 并且您可以根据进度更新开发邮件列表。当该功能准备好提交时，来自提交者的 3 + 1 将使您的功能合并。参见 HBase，邮件#dev - 关于大型功能开发分支的想法

如何在问题解决时在 JIRA 中设置修复版本

以下是我们在解决问题时同意在 JIRA 中设置版本的方式。如果 master 将是 2.0.0，而 branch-1 1.4.0 则是：

• 仅提交给 master：标记为 2.0.0

• 提交 branch-1 和 master：标记为 2.0.0 和 1.4.0

• 提交 branch-1.3，branch-1 和 master：标记为 2.0.0,1.4.0 和 1.3.x.

• 提交站点修复：没有版本

何时将 RESOLVED JIRA 设置为 CLOSED 的政策

我们同意对于在 _ 修正版/_ 字段中列出多个版本的问题，请关闭所列出的任何版本的发布问题;随后的问题变更必须在新的 JIRA 中进行。

只有 ZooKeeper 中的瞬态！

你应该能够杀死 zookeeper 中的数据，而 hbase 应该在它上面重新创建 zk 内容。这是围绕这些部分的古老谚语。我们现在才注意到它。我们目前也违反了这个基本原则 - 复制至少在 zk 中保持永久状态 - 但我们正在努力撤销这个打破黄金法则。

199.社区角色

199.1。发布经理

每个维护的发布分支都有一个发布管理器，他自愿协调新功能，并将错误修复程序反向移植到该发行版。发布经理是提交者。如果您希望将特性或错误修复包含在给定版本中，请与该版本管理器进行通信。如果此列表已过期或您无法联系到列出的人员，请与列表中的其他人联系。

此列表中不包括寿命终止版本。

200.提交消息格式

我们同意以下 Git 提交消息格式：

HBASE-xxxxx <title>. (<contributor>) 

如果提交者是贡献者，则不要使用'（<contributor>）'元素。</contributor>