如何往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