目前的提交者

成為提交者

若要開始為 Spark 做出貢獻，請了解 如何做出貢獻 – 任何人都可以提交程式碼修補程式、文件和範例給此專案。

PMC 會定期從活躍的貢獻者中新增提交者，根據他們對 Spark 的貢獻。新提交者的資格包括

1. 持續對 Spark 做出貢獻：提交者應有對 Spark 做出重大貢獻的紀錄。理想的提交者會對整個專案做出廣泛的貢獻，並至少貢獻一個他們已承擔「擁有者」角色的主要元件。擁有者角色表示現有的貢獻者認為他們應透過此人在這個元件上執行程式碼修補程式。
2. 貢獻品質：提交者應比其他社群成員更提交簡單、經過良好測試且設計良好的修正程式。此外，他們應展現足夠的專業知識，以便審查修正程式，包括確保它們符合 Spark 的工程實務（可測試性、文件、API 穩定性、程式碼風格等）。提交者集體負責 Spark 的軟體品質和可維護性。請注意，在評估品質時，對 Spark 的關鍵部分（例如其核心和 SQL 模組）的貢獻將會採用更高的標準。這些領域的貢獻者將面臨更多對其變更的審查。
3. 社群參與：提交者在所有社群互動中應具備建設性和友善的態度。他們也應積極參與開發人員和使用者清單，並協助指導較新的貢獻者和使用者。在設計討論中，提交者應維持專業且外交的態度，即使面對不同意見。

所考量的貢獻類型和層級可能因專案領域而異 - 例如，我們極力鼓勵想要主要從事文件工作或主要從事特定作業系統、儲存系統等的平台支援的貢獻者。

PMC 也會新增新的 PMC 成員。PMC 成員預期應執行 Apache 指南中所述的 PMC 職責，包括協助對版本進行投票、執行 Apache 專案商標、負責法律和授權問題，並確保專案遵循 Apache 專案機制。PMC 會定期將已展現出了解並能協助這些活動的提交者新增至 PMC。

審查程序

在合併之前，應審查所有貢獻，如 對 Spark 的貢獻 中所述。特別是，如果您正在從事不熟悉的程式碼庫領域，請查看該程式碼的 Git 歷程記錄，以查看之前審查修正程式的人員。您可以使用 git log --format=full <filename> 執行此操作，透過檢查「提交」欄位來查看提交每個修正程式的人員。

何時提交/合併拉取請求

在積極的、主題相關的討論期間，不得合併 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 遠端，以及在 git://github.com/apache/spark 新增一個稱為 apache-github 的遠端。

用於推送壓縮提交的遠端是 apache（PUSH_REMOTE_NAME 環境變數的預設值），用於拉取變更的遠端是 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 並「壓縮」您的新提交。在提交訊息後編輯，以移除您的提交訊息。您可以使用 git log 驗證結果是否為一個變更。然後在另一個視窗中繼續執行腳本。

此外，請記得在適用的情況下，在 JIRA 中設定已解決的任務的受讓人。在大部分情況下，腳本可以自動執行此操作。

一旦合併了公關，請在公關上留下評論，說明它已與哪些分支合併。

回溯錯誤修正的政策

來自 pwendell

回溯的權衡是，您可以將修正提供給執行舊版本的使用者（很棒！），但您冒著在維護版本中引入新的或更嚴重的錯誤的風險（糟糕！）。決策點是當您有錯誤修正，但尚不清楚是否值得回溯時。

我認為以下面向很重要

• 回溯是對社群極有價值的服務，應考慮對任何錯誤修正進行回溯。
• 必須不惜一切代價避免在維護版本中引入新錯誤。隨著時間推移，這會侵蝕我們對發佈程序的信心。
• 如果發行版或進階使用者認為合適，他們隨時可以自行回溯有風險的修補程式。

對我來說，這些後果是我們應該在以下情況下進行回溯

• 錯誤和修正都已充分理解且已隔離。修改的程式碼已經過充分測試。
• 要處理的錯誤是社群的優先要務。
• 回傳的修正並未與主分支修正有顯著差異。

我們傾向於在相反的情況中避免回傳。

• 錯誤或修正並未被充分理解。例如，它與複雜元件或第三方程式庫（例如 Hadoop 程式庫）之間的互動有關。程式碼在立即修正的錯誤之外並未經過充分測試。
• 該錯誤顯然不是社群的高優先順序。
• 回傳的修正與主分支修正有顯著差異。