贡献

相关源文件

• CONTRIBUTING.md
• DCO
• Documentation/contributor-guide/branch_management.md
• Documentation/contributor-guide/community-membership.md
• Documentation/contributor-guide/features.md
• Documentation/contributor-guide/release.md
• Documentation/contributor-guide/triage_issues.md
• Documentation/contributor-guide/triage_prs.md
• GOVERNANCE.md
• OWNERS
• README.md
• scripts/release_notes.tpl.txt

本文档为贡献 etcd 项目提供了全面的指南。它解释了从查找 issue 到提交 pull request 的贡献流程，以及社区结构和对贡献者的期望。有关构建和测试 etcd 的信息，请参阅 构建与测试。

快速入门

在贡献 etcd 之前，您应该熟悉该项目、其架构和开发工作流程。

了解 etcd

要有效地为 etcd 做贡献，您首先应该了解该项目

1. 了解 etcd 使用的 Git 版本控制系统。
2. 阅读 etcd 学习资源
3. 观看 etcd 深度解析 和 etcd 代码解析

来源： CONTRIBUTING.md19-27

设置开发环境

有两种支持的设置开发环境的选项。

选项 1：手动设置（传统）

这是 etcd 的原始开发环境。

1. 克隆仓库
2. 安装 Go（在 go.mod 中检查最低版本）。
3. 安装所需的构建工具
   • make
   • protoc (v3.20.3)
   • yamllint
   • jq
   • xz
4. 使用 make build 验证安装。

选项 2：Devcontainer（较新）

对于 etcd v3.6+，您可以使用 devcontainer，它提供了自动化的设置。

1. 与 Visual Studio Code 和 Docker 一起使用。
2. 或者，使用 GitHub Codespaces。

这种方法提供了一个具有所有必需工具的完全配置的环境。

来源： CONTRIBUTING.md78-130

找点事情做

etcd 项目在 GitHub issue tracker 中跟踪所有工作。有几种方法可以找到需要处理的 issue：

• 新贡献者：从标记为 good first issue 的 issue 开始。
• 更有经验：查找标记为 help wanted 的 issue。
• 高级贡献者：查看标记为 priority/important 的 issue。
• 测试改进者：查找 flaky test issues 的 issue。

来源： CONTRIBUTING.md29-77

贡献工作流程

为 etcd 贡献的通用工作流程遵循以下步骤：

实施您的更改

在实施更改时，请遵循以下指南：

1. 遵循 Golang 社区建议的 Go 编码风格。
2. 确保您的更改通过静态分析。
   • 运行 make verify 来执行所有检查。
   • 运行 make fix 来修复所有检查。
3. 确保您的更改通过测试。
   • 运行 make test-unit 来运行单元测试。
   • 运行 make test-integration 来运行集成测试。
   • 运行 make test-e2e 来运行端到端测试。
4. 所有更改都应附带单元测试。
5. 新功能应包含 e2e 或集成测试。

来源： CONTRIBUTING.md132-151

提交您的更改

etcd 遵循特定的提交消息约定。

1. 第一行：应以包名开头，后跟冒号（例如，etcdserver:）。
2. 第一行（续）：描述更改的作用。
3. 正文：可选，解释为什么进行更改。
4. 最后一行：包含 Signed-off-by: firstname lastname <email@example.com>。

示例

etcdserver: add grpc interceptor to log info on incoming requests

To improve debuggability of etcd v3. Added a grpc interceptor to log
info on incoming requests to etcd server. The log output includes
remote client info, request content (with value field redacted), request
handling latency, response size, etc. Uses zap logger if available,
otherwise uses capnslog.

Signed-off-by: FirstName LastName <github@github.com>

来源： CONTRIBUTING.md152-172

创建拉取请求 (Pull Request)

创建拉取请求时

1. 遵循 making a pull request 指南。
2. 如果仍在进行中，请转换为草稿状态。
3. 倾向于提交多个小的 PR，而不是单个大的 PR（代码量超过 500 行）。
4. 确保每个 PR 都有一个相关的 issue。
5. 在 PR 合并且有必要回溯移植之前，不要关闭 issue。

来源： CONTRIBUTING.md174-185

获取您的 Pull Request 审查

在请求审查之前

1. 确保所有 GitHub 和 Prow 检查都成功。
2. 如果您的 PR 具有 needs-ok-to-test 标签，则组织成员需要评论 /ok-to-test。
3. 对于失败的不相关测试，请提交 issue 并请求维护者重新运行测试。
4. 联系参与原始讨论或维护者以获取审查。
5. 根据 PR 的复杂性，需要 1-2 名维护者批准才能合并。

来源： CONTRIBUTING.md187-197

社区结构

etcd 项目拥有一个定义完善的社区结构，包含各种角色和职责。

角色	职责	要求	由...定义
成员	活跃贡献者	多次贡献，由 2 名审查者赞助	etcd GitHub 组织成员
审查者	审查贡献。	审查和作者身份的历史记录，作为成员 3 个月以上。	查看 OWNERS 文件中的审查者条目。
维护者	设定方向和优先级	展示责任感和技术判断力。	查看 OWNERS 文件中的批准者条目。

维护者

维护者是项目长期成功方面表现出承诺的贡献者。他们进行和批准技术设计决策，设定技术方向，定义里程碑，并确保项目的持续健康。

当前维护者列在 OWNERS 文件中。

• Benjamin Wang (@ahrtr)
• Wei Fu (@fuweid)
• James Blair (@jmhbnz)
• Marek Siarkowicz (@serathius)
• Sahdev Zala (@spzala)
• Wenjia Zhang (@wenjiaswe)

来源： Documentation/contributor-guide/community-membership.md1-170 和 OWNERS1-13

问题与 PR 管理

Issue Triage 流程

etcd 项目使用标签来指示 issues 的常见属性，例如 area、type 和 priority。

Triage issues 的步骤：

1. 检查 issue 是否有效并属于 etcd。
2. 应用适当的类型标签（type/bug、type/feature、type/flake 等）。
3. 使用 area/* 标签定义受影响的区域。
4. 使用 priority/* 标签确定 issue 的优先级。
5. 考虑为新贡献者添加 good first issue 或 help wanted 标签。
6. 跟进 issue，防止其过时。

来源： Documentation/contributor-guide/triage_issues.md1-193

PR 管理

有效管理 pull request 对项目的健康至关重要。

1. 通过评论 /ok-to-test 来确保 PR 上的测试已运行，前提是 PR 具有 needs-ok-to-test 标签
2. 通过在 PR 进入不活动状态 15 天后通知 PR 所有者来处理不活动的 PR
3. 在 180 天不活动后关闭不活动的 PR
4. 验证重要的标签是否已设置（审阅者、里程碑等）

来源： Documentation/contributor-guide/triage_prs.md1-33

分支管理和发布流程

分支管理

etcd 遵循滚动发布模型，支持两个稳定版本

• 主分支：所有新功能最先合并到此开发分支
• 稳定分支：所有带有 release- 前缀的分支都是稳定分支
  • 在每个次要版本发布后创建
  • 仅应用向后兼容的 bug 修复
  • 支持最新的两个稳定版本

来源： Documentation/contributor-guide/branch_management.md1-26

发布流程

etcd 项目有一个专门的发布管理团队，负责

1. 沟通每个版本的计划和状态
2. 确保发布分支的稳定性
3. 管理主要/次要版本发布和预发布
4. 将补丁回溯到稳定版本

发布流程包括：

• 确保里程碑已完成
• 更新文档
• 准备发布说明
• 构建和发布二进制文件及容器镜像
• 向社区宣布发布

来源： Documentation/contributor-guide/release.md1-132

功能开发指南

etcd 中的功能遵循一个分阶段的方法，类似于 Kubernetes

功能阶段

阶段	特性	默认启用	支持策略
Alpha	可能存在 bug，测试较少	否	可能在不通知的情况下弃用
Beta	在发布版本中受支持	是	必须遵循弃用策略
GA (普遍可用)	完全支持	始终启用	必须遵循弃用策略

添加新功能

新功能通常作为 Alpha 功能添加，遵循以下步骤

1. 打开一个 KEP (Kubernetes Enhancement Proposal) 问题
2. 创建一个 KEP Pull Request，包含升级标准
3. 实现该功能并添加相应的测试
4. 添加一个 Alpha 功能门
5. 至少需要两名维护者批准

来源： Documentation/contributor-guide/features.md1-87

开发者来源证书

etcd 使用开发者来源证书 (DCO) 来进行贡献。通过贡献，您证明：

1. 您创建了该贡献，并且有权提交它，或者
2. 该贡献是基于之前受开源许可证覆盖的作品，或者
3. 该贡献是由某人提供给您，并且该人已证明以上内容

您必须通过 git commit --signoff 来签署您的提交，以表示同意。

来源： DCO1-37

社区会议

etcd 社区定期举行会议

• 每周四上午 11:00 (美国太平洋时间) 举行会议
• 在社区会议和问题分类会议之间交替举行
• 会议对所有贡献者开放
• 会议录像会上传到 YouTube 频道

联系渠道

• 邮件： etcd-dev
• Slack： Kubernetes Slack 上的 #sig-etcd 频道

来源： README.md139-161