如何往Spark社区做贡献，贡献代码

随着社区正在努力准备Apache Spark的下一版本3.0，您可能会问自己“我如何参与其中？”。现在的Spark代码已经很庞大，因此很难知道如何开始自己做出贡献。Spark PMC & Committer Holden Karau以开发人员为中心，教你如何为Spark社区做贡献，逐步发现好的问题点，格式化代码，寻找代码评审者以及在代码评审过程中期望得到什么。除了如何编写代码之外，她还探讨Apache Spark做出贡献的其他方法，从帮助测试RC(Release Candidate)版本，到进行所有重要的代码评审，错误分类等等，也包括例如回答别人的技术问题。

Apache Spark社区已经有大量中国人的身影，在国内也常常有开发者线下聚会研讨，本文末尾也有示说网参与的上海和杭州地区Apache开源社区活动（完全免费），可以了解目前开源技术社区的前沿动态。

文末可以查看Holden演讲视频（含中英字幕），以下为PPT原文截图和核心要点整理，希望对如何贡献Apache Spark开源社区的同学有一定启发。

 

本文是基于Holden Karau在2019年Spark Summit EU上的分享视频整理而成，按照Holden自己的说法，不代表Spark PMC的观点，（虽然Holden是Spark PMC & Committer），仅仅是她个人的建议和看法，供广大开发者朋友参考。

 

主要讨论如下几个方面：

• 目前Spark开发社区的状态；
• 为什么要给Apache Spark做贡献；
• 给Spark社区做贡献的几个途径；
• 如何找到可以参与贡献；
• 贡献代码和文档修改，可能用到的工具集合；

 

作为Spark的PMC，她认为你可能有如下几个原因，期待能够给Spark社区做出贡献：

• 修复工作中碰到的Spark的bug或者问题
• 学习分布式系统
• 强化你在Scala/Python/R/Java等语言的技能
• 函数式编程的奇技淫巧
• 个人成长的光辉记录和成就感，（或许有利于找到更好的工作？）
• 基于Spark弄点有意思的事

 

如何向Spark做出自己的贡献？

• 直接提交相关的代码修改
• Spark Package中的代码修改
• 帮助审查Spark代码
• Spark周边的库代码
• Spark书籍，技术分享，技术博客等
• 在Spark邮件列表，StackOverflow等地方回答技术问题
• Spark测试和发行的验证工作

 

当然，每个人对于Spark的熟悉程度不一样，这个和每个人的工作内容及兴趣有很大关系，Holden列举了相关的工作涉及到的具体内容和问题。

 

 

 

假如你希望能从直接为Spark贡献代码：

• 或许你碰到了Spark的bug并希望修复它
• 或许你希望给Spark增加新的特性
• 你得先看看你的想法有没有人已经着手在做了
• 如果你期待的代码改动比较复杂，除非你已经有相当的经验，否则最好还是挑个简单的开始
• 千万别一意孤行，干起来再说，至少得先看看http://spark.apache.org/contributing.html 或者读完本文

 

既然已经下定决心要为Spark做点代码的活，那么先了解一下Spark 3.0目前的模块。

 

开始之前你还需要了解，Spark的任何改动，都会关联一个JIRA的Issue，你得先注册JIRA，然后关注JIRA上面的Spark社区动静。这个不是Spark独有的，貌似基本上所有的Apache开源项目都是通过JIRA来跟踪各种问题。

 

基本上JIRA里会包含别人发现，或者计划要做的那些事，如果你想修复一个bug或者增加新的特性，先查查JIRA上有没有人已经提了类似的Issue，如果没有，那很好，你可以创建一个JIRA，并且告诉别人你已经着手做了，当然，你也可以挑一个别人没有着手做的Issue，自己先干起来，当然，干之前你需要在Issue里留下点文字，告诉其他人你已经在做这个共组了。

 

JIRA里不太适合分配任务（通常这是committer们的活），也不太适合把很长的设计文档放到上面，更好的做法是，把设计文档用google doc来做，然后再JIRA相关的issue下，粘贴以下设计文档的链接，在国内的朋友，你可能还要多一个“fq”用Google Doc的步骤。

 

在JIRA中，找个简单适合初次贡献Spark代码的小技巧。

 

还可以在代码中grep一把，看看代码里留下的“TODO”注释，或许你可以从中找点灵感。

 

大的Spark特性或者改动，需要先提交SPIP（Spark Project Improvement Proposals）,会有很多熟悉相关模块的committer和contributor参与到这个修改建议的讨论，等代码都打成默契了，再来决定谁来干，怎么干。

 

你得熟悉github的玩法，视频原文中有详细的介绍。

 

怎么编译spark，这里比较简单，实际上的编译工作会涉及到很多的环境参数，还得fq，这个很重要。

 

如果修改代码可能有点难，也可以先考虑修改文档，文档中的错误总是特别容易出现，而且，一旦修改好后，总是很快会被合并到代码主干。

 

文档的生成工具

 

找一个你擅长的开发工具和Spark模块。

 

测试。。

 

代码写好了之后，是否符合spark社区的代码规范呢?http://spark.apache.org/contributing.html#code-style-guide 对应有Scala/Java/Python/R等语言的规范，还有Spark社区自己的规范。

 

MiMa是验证二进制兼容性的工具，确保在不同版本间API的兼容性得到检测，当然这玩意比较敏感，有时候API不兼容是实现设计上的改动，特别是3.0 API的出现，确实会有很多东西和以前不兼容了。

 

好了，当你已经完成代码改动和测试，终于可以提交PR了。提交之前还有些步骤，报名PR的名称规范，视频原文有演示，有一个网站不要错过：https://spark-prs.appspot.com/ （很不幸，还得fq）

 

代码PR已经创建后，会有代码评审环节，参与代码评审的人，也是值得尊敬的，是每个contributor成长和帮助别人成长的过程。

 

找到合适的人帮你评审代码，通常最后把关的是Spark的Committer们，当然不是每个Committer都熟悉所有的模块，需要找对合适的人比较重要，你可以@相关模块的活跃committer，他们通常都会很热心的回复你。

 

终于到了著名的：LGTM / SGTM，你离代码合并又近了一步。

 

实际操作PR的一些小建议

 

当然，PR很多时候是没有办法被合并的，原因和理由有时候会比较难以启口，任何时候都不要沮丧。

 

代码设计上每个人都有自己的思考和想法，慢慢积累自己的思考，深入了解Spark社区对于代码的规则和要求，你会进步很快的。

 

当然，有些问题可能和你没有关系，或者committer们太忙，或者jenkins不工作了，或者jenkins不帮你的PR做自动化测试了，大胆的ping committer们。

 

 

 

 

以人为本，共建和谐社区！以下是各种小建议：

 

 

社区不是独立存在的，而是来自全球1500名工程师参与探讨的地方，任何大的改动之前，请先知会社区，善于利用邮件列表来沟通。当然，现在会讲普通话的开发者和committer及PMC们越来越多，可以多参加示说网上关于各种大数据相关的技术交流社区，可以面对面和社区大神们探讨技术和技术以外的道道。

（全文完）

视频（中英文字幕）见：https://www.slidestalk.com/Spark/GettingStartedContributingtoApacheSparkFromPRCRJIRAandBeyond?video

另外，欢迎关注开源技术社区的相关内容研讨：

1）看点：由中国计算机学会(CCF)组织举办的，Alluxio / Hadoop / HBase / Flink / Spark PMC和Committer聚首探讨各自社区的最新动态和发展方向。

https://www.slidestalk.com/m/64

2）看点：由阿里云EMR团队和Intel大数据技术团队联合举办，分享Spark在云端环境中的优化及在AI和数据分析领域的最新动态。

https://www.slidestalk.com/m/61

3）看点：由StreamNative举办，分享ApachePulsar的动态，您可以和该项目的主创人员好好交流社区开发心得。

https://www.slidestalk.com/m/65