当前提交者

如何成为提交者

要开始为 Spark 贡献，请了解如何贡献——任何人都可以向项目提交补丁、文档和示例。

PMC 根据活跃贡献者对 Spark 的贡献，定期增加新的提交者。新提交者的资格包括：

1. 持续对 Spark 做出贡献：提交者应有对 Spark 做出重大贡献的历史。理想的提交者将对项目的各个方面做出广泛贡献，并且至少在一个主要组件中承担“所有权”角色。所有权角色意味着现有贡献者认为他们应该由该人员审查该组件的补丁。
2. 贡献质量：提交者比任何其他社区成员都更应该提交简洁、经过充分测试和精心设计的补丁。此外，他们应展示足够的专业知识以审查补丁，包括确保它们符合 Spark 的工程实践（可测试性、文档、API 稳定性、代码风格等）。提交者群体集体负责 Spark 的软件质量和可维护性。请注意，对 Spark 关键部分（如其核心和 SQL 模块）的贡献，在评估质量时将遵循更高的标准。对这些领域的贡献者将面临更严格的更改审查。
3. 社区参与：提交者在所有社区互动中都应持有建设性和友好的态度。他们还应该积极参与开发者和用户邮件列表，并帮助指导新的贡献者和用户。在设计讨论中，即使存在分歧，提交者也应保持专业和外交的态度。
4. Apache 之道：提交者应遵循并理解Apache 之道，例如懒惰共识。Apache 项目独立管理。

一个明显以某种排他方式偏袒某个特定供应商的社区，通常会劝退来自竞争供应商的新贡献者，这会影响项目的长期健康发展。

所考虑的贡献类型和级别可能因项目领域而异——例如，我们非常鼓励主要致力于文档或主要致力于特定操作系统、存储系统等平台支持的贡献者。

PMC 还会增加新的 PMC 成员。PMC 成员应履行Apache 指南中描述的 PMC 职责，包括协助发布投票、执行 Apache 项目商标、负责法律和许可问题，并确保项目遵循 Apache 项目机制。PMC 定期将那些表明理解并能协助这些活动的提交者纳入 PMC。

审查流程

所有贡献都应在合并前进行审查，如贡献 Spark 中所述。特别是，如果您正在处理不熟悉的代码库区域，请查看该代码的 Git 历史记录，了解之前是谁审查了补丁。您可以使用git log --format=full <filename>来完成此操作，通过检查“Commit”字段来查看谁提交了每个补丁。

何时提交/合并拉取请求

除非涉及公共漏洞的关键安全修复等问题，否则拉取请求不应在活跃的、与主题相关的讨论期间合并。在特殊情况下，拉取请求可以在活跃的、与主题无关的讨论期间合并，并将讨论引导到更合适的场合。在合并之前应给予参与对话的人员时间来解释他们是否认为讨论与主题相关。

懒惰共识要求留出时间让讨论平息，同时理解人们可能不会将 Spark 作为全职工作，并且可能会休假。我们相信通过这样做，可以限制人们行使否决权的频率。

所有附带理由的“-1”都值得讨论。来自非提交者的“-1”只有在多名提交者输入的情况下才能被推翻，并且必须为任何提交者提供适当的时间来提出异议。来自无法联系到的提交者的“-1”需要根据 ASF 投票规则由 PMC 进行共识投票，以在ASF 代码否决指南内确定后续步骤。

这些政策旨在重申核心原则：代码不得在存在待决否决或未达成共识（无论是懒惰共识还是其他共识）之前合并。

PMC 希望否决权仍然不常发生，并且当它们发生时，所有各方都会在进一步的功能开发之前花时间建立共识。

成为一名提交者意味着在与持有不同观点的人们组成的社区中工作时，需要运用您的判断力。当您不确定时，寻求第二（或第三或第四）意见并没有错。感谢您对 Spark 项目的奉献；Spark 的开发者和用户对此表示赞赏。

希望这些指南不会减缓开发；相反，通过消除一些不确定性，目标是让我们更容易达成共识。如果您对如何改进这些指南或其他 Spark 项目操作程序有想法，您应该在 dev@ 邮件列表中提出以开始讨论。

如何合并拉取请求

推送到 Apache master 分支的更改无法移除；也就是说，我们不能强制推送到它。所以请不要添加任何测试提交或类似的东西，只添加真正的补丁。

设置远程仓库

要使用下面描述的merge_spark_pr.py脚本，您需要添加一个名为apache的 git 远程仓库，地址为https://github.com/apache/spark，以及一个名为apache-github的远程仓库，地址为git://github.com/apache/spark。

apache（PUSH_REMOTE_NAME环境变量的默认值）是用于推送压缩提交的远程仓库，而apache-github（PR_REMOTE_NAME的默认值）是用于拉取更改的远程仓库。通过为这两个操作使用两个独立的远程仓库，可以通过在PUSH_REMOTE_NAME变量中指定您的分支来测试merge_spark_pr.py的结果，而无需将其推送到官方 Spark 仓库。

克隆您的 Spark 分支后，您已经有一个名为origin的远程仓库指向那里。因此，如果正确，您的git remote -v至少包含以下几行：

apache	git@github.com:apache/spark.git (fetch)
apache	git@github.com:apache/spark.git (push)
apache-github	git@github.com:apache/spark.git (fetch)
apache-github	git@github.com:apache/spark.git (push)
origin	git@github.com:[your username]/spark.git (fetch)
origin	git@github.com:[your username]/spark.git (push)

对于apache仓库，您需要设置 GitHub 的命令行认证。这可能包括设置 SSH 密钥和/或个人访问令牌。请参阅：

• https://docs.github.com/en/authentication/connecting-to-github-with-ssh
• https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens

要检查是否已授予必要的写入权限，请访问GitBox。

如果您在这些步骤中遇到问题，或者需要第一次合并的帮助，请咨询dev@spark.apache.org。

合并脚本

所有合并都应使用dev/merge_spark_pr.py脚本完成，该脚本会将拉取请求的更改压缩为一个提交。

该脚本相当简单明了，会以交互方式引导您完成步骤和选项。

如果您想在合并前修改提交——这应该用于微小的修饰——那么只需让脚本在询问您是否要推送到 Apache 时等待。然后，在另一个窗口中，修改代码并推送一个提交。运行git rebase -i HEAD~2并“压缩”您的新提交。紧接着编辑提交消息以删除您的提交消息。您可以使用git log验证结果是一项更改。然后恢复另一个窗口中的脚本。

此外，请记住在 JIRA 解决时，如果适用，设置指派人。脚本在大多数情况下可以自动完成此操作。

一旦拉取请求合并，请在拉取请求上留下评论，说明它已合并到哪个分支。

关于回溯错误修复的政策

来自pwendell

回溯时的权衡是，您可以将修复交付给运行旧版本的人员（太好了！），但您可能会在维护版本中引入新的甚至更糟糕的错误（糟糕！）。决策点是当您有一个错误修复时，不清楚是否值得回溯。

我认为以下几个方面很重要，需要考虑：

• 回溯是对社区非常有价值的服务，应考虑对任何错误修复进行回溯。
• 在维护版本中引入新错误必须不惜一切代价避免。这会随着时间的推移侵蚀人们对我们发布流程的信心。
• 发行版或高级用户如果认为合适，可以自行回溯有风险的补丁。

对我来说，这些的结论是，我们应该在以下情况下进行回溯：

• 错误和修复都得到了很好的理解和隔离。正在修改的代码经过了充分测试。
• 正在处理的错误对社区来说是高优先级的。
• 回溯的修复与 master 分支的修复没有太大差异。

在相反的情况下，我们倾向于避免回溯：

• 错误或修复不被充分理解。例如，它与复杂组件或第三方库（例如 Hadoop 库）之间的交互有关。除了正在修复的直接错误之外，代码没有经过充分测试。
• 该错误对社区来说并非明确的高优先级。
• 回溯的修复与 master 分支的修复存在显著差异。