现任提交者

成为提交者

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

项目管理委员会 (PMC) 会根据活跃贡献者对 Spark 的贡献，定期增选新的提交者。新提交者的资格要求包括：

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

如果一个社区明显偏袒某一家特定的供应商，往往会阻碍来自竞争对手供应商的新贡献者加入，这对于项目的长期健康发展将是一个问题。

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

PMC 也会增选新的 PMC 成员。PMC 成员需要履行 Apache 指南 中所述的 PMC 职责，包括协助投票表决发布版本、执行 Apache 项目商标、承担法律和许可问题的责任，并确保项目遵循 Apache 项目机制。PMC 会定期将已展现出理解并能协助处理这些活动的提交者增选为 PMC 成员。

审查流程

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

何时提交/合并拉取请求 (PR)

除非 PR 涉及公共漏洞的紧急安全修复等问题，否则不得在活跃的、切题的讨论期间进行合并。在极端情况下，可以在活跃的、偏离主题的讨论期间合并 PR，并将讨论引导至更合适的场所。在合并之前，应留出时间让参与对话的人员解释他们认为其讨论是切题的。

懒惰共识要求留出时间让讨论平息，同时也要理解人们可能不是全职为 Spark 工作，且可能会休假。我们相信通过这样做，可以减少人们感到有必要行使否决权的情况。

所有带有正当理由的 -1 评价都值得讨论。来自非提交者的 -1 评价，只有在多名提交者输入意见后才能被推翻，且必须给予任何提交者提出担忧的适当时间。如果无法联系到给出 -1 的提交者，则需要根据 ASF 投票规则，通过 PMC 的共识投票来决定接下来的步骤，具体请参考 ASF 关于代码否决权的准则。

这些政策重申了核心原则：不得在存在待处理否决权的情况下，或在达成共识（懒惰或其他形式）之前合并代码。

PMC 希望否决权保持在极低频率，且当其发生时，各方都能花时间在进行进一步的功能开发之前建立共识。

作为一名提交者，意味着在与拥有不同观点的人员组成的社区中工作时，要运用自己的判断力。当您不确定时，寻求第二（或第三、第四）意见并无不妥。感谢您对 Spark 项目的奉献；Spark 的开发者和用户对此不胜感激。

希望这些准则不会减慢开发速度；相反，通过消除一些不确定性，我们的目标是使我们更容易达成共识。如果您有关于如何改进这些准则或其他 Spark 项目操作流程的想法，请在 dev@ 列表中发起讨论。

如何合并拉取请求

推送到 Apache 主分支的更改无法移除；也就是说，我们不能对主分支进行强制推送 (force-push)。所以请不要添加任何测试性提交或类似内容，只提交真正的补丁。

设置远程仓库

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

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

克隆您的 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 并“压缩” (squash) 您的新提交。随后编辑提交信息以删除您的提交信息。您可以使用 git log 验证结果是否为一次更改。然后回到另一个窗口恢复脚本执行。

此外，请记住在解决 JIRA 问题时适当地设置受理人 (Assignee)。在大多数情况下，脚本可以自动完成此操作。

一旦 PR 合并，请在 PR 上发表评论，说明它已合并到哪个或哪些分支。

关于向后移植 (backporting) 错误修复的政策

来自 pwendell

向后移植的权衡在于：您可以将修复程序提供给使用旧版本的用户（很好！），但您也冒着在维护版本中引入新的甚至更严重漏洞的风险（很坏！）。决策点在于，当您有一个错误修复程序，但不确定是否值得进行向后移植时。

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

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

对我而言，这些结论意味着我们应该在以下情况下进行向后移植：

• 错误和修复方法都已得到充分理解且相互独立。被修改的代码经过了充分的测试。
• 所处理的错误对社区来说是高优先级的。
• 向后移植的修复程序与 master 分支上的修复程序没有太大差异。

在相反的情况下，我们倾向于避免向后移植：

• 错误或修复方法未得到充分理解。例如，它涉及复杂组件或第三方库（如 Hadoop 库）之间的交互。除了被修复的即时错误外，代码未经过充分测试。
• 该错误显然不是社区的高优先级问题。
• 向后移植的修复程序与 master 分支上的修复程序差异很大。