Development

OpenTSDB 在 Producing 运行 TSD 的用户群不断壮大。还有许多才华横溢的开发人员为 OpenTSDB 创建工具或直接向项目贡献代码。如果您有兴趣通过添加新功能，修复错误，添加工具或仅更新文档来提供帮助，请阅读以下指南。然后签署贡献者协议并向我们发送请求请求！

如果您希望将 OpenTSDB 与您的应用程序集成，则已编译的 JAVA 库具有一致且记录良好的 API。请参阅JAVA API 文档。

Guidelines

• 请检查是否有人发布了错误后提交GitHub 上的问题。确保您的错误报告包含足够的详细信息，以便其他人可以轻松理解并快速修复。

• 阅读开发页面以获取提示

• 贡献代码的最佳方法是在 GitHub 上派生主仓库和发送请求请求。

• 错误修复应在master分支中完成

  • 新功能或重大更改应在next分支中完成

• 或者，您可以将纯文本补丁发送到mailing list。

• 在可以包含您的代码更改之前，请提交贡献许可协议。

• 与 Apache 软件基金会不同，我们不需要将每个代码更改都附加到问题上。随意发送所需的许多小补丁。

• 请将您的更改分解为尽可能小的提交。

• 请尊重您要更改的代码的编码风格。

• 缩进代码，带有 2 个空格，没有制表符

  • 将代码保持在 80 列

  • 与if，for，while等位于同一行的大括号

  • 变量需要描述性名称like_this(而不是典型的 Java 样式likeThis)

  • 以小写字母开头的名为likeThis()的方法

  • 名为LikeThis的类，以大写字母开头

  • 尽量使用final关键字，尤其是在方法参数和 return 语句中。

  • 尽可能避免检查异常

  • 始终向类和成员提供最严格的可见性

  • Javadoc 您所有的类和方法。有些人直接使用 Java API，我们将为该站点构建文档，因此越多越好

  • 除非绝对必要，否则请勿将依赖项添加到核心 OpenTSDB 库中

  • 为您创建的任何类/方法添加单元测试，并确认所做的更改不会破坏现有的单元测试。我们知道 UT 不好玩，但它们很有用

Git Repository

OpenTSDB 在GitHub中维护。分支机构数量有限，每个分支机构的用途如下：

• maintenance-这是以前发行的 OpenTSDB 版本，通常是最后一个次要版本。例如。如果当前版本为 2.3.0 或 2.3.1，则maintenance将具有最新的 2.2.x 版本。该分支应该很少有 PR 指向它。可以选择适用于以前版本的master补丁。

• master-OpenTSDB 的当前发行版。只能针对master给出具有错误修复的请求请求。合并足够的 PR 后，我们将剪切另一个 PATCH 版本，例如 2.2.0 至 2.2.1. 具有新功能或行为修改的修补程序应指向next。针对 master 的补丁应精选到下游分支。

• next-这是 OpenTSDB 的下一个次要发行版本，其中包含开发中的代码，或者，当该版本标记为 RC 时，则包含候选代码。如果版本标记为 SNAPSHOT，则可以将新功能应用于下一个。一旦移至 RC，则应针对put分支发布新功能。否则，仅应为 RC 代码提供错误修复。

• put-当next分支处于 RC 状态时，应将新功能应用于put，它将是下一个次要版本。

• X.0-OpenTSDB 的下一个主要版本，可能包括重大的 API 更改。当代码处于相当稳定的状态时，它将提升为 RC 的next，然后提升为master正式发布。

任何其他分支都可能在某个时候被修剪，因为它们可能包含过时的代码或临时的 hack。

Details

• General Development

• Plugins

• HTTP API