当前贡献者

成为贡献者

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

PMC 定期从活跃贡献者中添加新的贡献者，根据他们对 Spark 的贡献。新贡献者的资格包括

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

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

PMC 还添加新的 PMC 成员。PMC 成员应履行 PMC 职责，如 Apache 指南 中所述，包括帮助投票发布、执行 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 上的 master 分支的更改无法删除；也就是说，我们不能强制推送它。因此，请不要添加任何测试提交或类似内容，只添加真正的补丁。

设置远程仓库

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

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	[email protected]:apache/spark.git (fetch)
apache	[email protected]:apache/spark.git (push)
apache-github	[email protected]:apache/spark.git (fetch)
apache-github	[email protected]:apache/spark.git (push)
origin	[email protected]:[your username]/spark.git (fetch)
origin	[email protected]:[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。

如果您在这些步骤中遇到问题，或者需要帮助进行第一次合并，请询问 [email protected]。

合并脚本

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

该脚本相当自解释，并以交互方式引导您完成步骤和选项。

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

此外，请记住在适用时在 JIRA 上设置 Assignee，当它们被解决时。该脚本可以在大多数情况下自动执行此操作。

合并 PR 后，请在 PR 上留下评论，说明它已合并到哪个分支（分支）。

关于错误修复回退的策略

来自 pwendell

回退的权衡是，你可以将修复程序交付给运行旧版本的人（很棒！），但你也有可能在维护版本中引入新的甚至更糟糕的错误（糟糕！）。决定点是当你有一个错误修复，但还不清楚是否值得回退。

我认为以下方面很重要：

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

对我来说，这些结果意味着我们应该在以下情况下进行回退：

• 错误和修复都得到了很好的理解和隔离。被修改的代码经过了充分的测试。
• 社区高度重视要解决的错误。
• 回退的修复与主分支修复没有太大差异。

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

• 错误或修复没有得到很好的理解。例如，它与复杂组件或第三方库（例如 Hadoop 库）之间的交互有关。代码在修复的直接错误之外没有经过充分的测试。
• 社区对错误的优先级并不高。
• 回退的修复与主分支修复有很大差异。