当前提交者

成为提交者

要开始为 Spark 做出贡献，请学习如何贡献 - 任何人都可以向项目提交补丁、文档和示例。

PMC 会定期从活跃的贡献者中添加新的提交者，这是基于他们对 Spark 的贡献。 新提交者的资格包括

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

明显偏袒某个特定供应商的社区通常会阻止来自竞争供应商的新贡献者，这对项目的长期健康构成问题。

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

PMC 还会添加新的 PMC 成员。 PMC 成员应按照 Apache 指南中的描述履行 PMC 职责，包括帮助投票发布版本、执行 Apache 项目商标、负责法律和许可问题，并确保项目遵循 Apache 项目机制。 PMC 定期将已经证明他们理解并可以帮助进行这些活动的提交者添加到 PMC。

审查流程

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

何时提交/合并拉取请求

除非解决公共漏洞的关键安全修复程序等问题，否则在积极的、主题内的讨论期间不得合并 PR。 在特殊情况下，可能会在积极的、主题外的讨论期间合并 PR，并将讨论引导到更合适的场所。 在合并之前应该留出时间，让参与对话的人解释他们是否认为自己与主题相关。

惰性共识要求留出时间进行讨论，同时理解人们可能不会将 Spark 作为他们的全职工作，并且可能会休假。 据信，通过这样做，我们可以限制人们感到需要行使否决权的情况。

所有带有理由的 -1 都值得讨论。 来自非提交者的 -1 只能在多个提交者的参与下才能被推翻，并且必须提供足够的时间让任何提交者提出疑虑。 来自无法联系到的提交者的 -1 需要 PMC 根据 ASF 投票规则进行一致投票，以确定 ASF 代码否决指南中的后续步骤。

这些策略旨在重申核心原则，即不得在存在未决否决权或未达成共识（无论是惰性的还是其他的）之前合并代码。

PMC 希望否决权继续很少发生，并且当发生时，所有各方都将花时间在额外功能工作之前达成共识。

成为提交者意味着在与具有不同观点的人们组成的社区中工作时运用您的判断力。 当您不确定时，获得第二个（或第三个或第四个）意见并没有什么不妥。 感谢您对 Spark 项目的奉献； Spark 的开发者和用户都对此表示感谢。

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

如何合并拉取请求

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

设置远程仓库

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

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

克隆 Spark 的 fork 后，您已经有一个指向那里的远程仓库 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 上设置受让人（如果适用）。 在大多数情况下，脚本可以自动执行此操作。

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

关于向后移植错误修复的策略

来自 pwendell

向后移植的权衡在于，您可以将修复程序交付给运行旧版本的用户（非常好！），但您有可能会在维护版本中引入新的，甚至更糟糕的错误（不好！）。关键的决策点在于，当您有一个错误修复时，不确定是否值得向后移植。

我认为以下几个方面很重要

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

对我而言，这些的后果是，我们应该在以下情况下向后移植

• 错误和修复程序都已得到很好的理解和隔离。正在修改的代码经过了充分的测试。
• 所解决的错误对于社区来说是高度优先的。
• 向后移植的修复程序与主分支修复程序没有太大差异。

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

• 对错误或修复程序没有很好的理解。 例如，它与复杂组件或第三方库（例如 Hadoop 库）之间的交互有关。除了正在修复的直接错误之外，该代码没有经过很好的测试。
• 该错误显然不是社区的高度优先事项。
• 向后移植的修复程序与主分支修复程序差异很大。