摘要

本 PEP 提議投入資源，自動化目前 CPython 核心開發團隊在合併更改時所需的一些繁瑣、耗時的工作。此提案旨在讓核心開發者更有效地利用他們為 CPython 貢獻的時間，這也有望改善依賴核心團隊合併更改的其他貢獻者的體驗。

PEP 撤回

本 PEP 已被作者撤回，以支援 PEP 507 中基於 GitLab 的提案。

如果其他人想接手並倡導此 PEP，請聯絡 core-workflow 郵件列表

核心開發工作流變更的理由

CPython 核心開發者在 POSIX 系統上合併新功能的當前工作流程“如下”：

1. 如果應用由其他使用者提交到 bugs.python.org 的更改，首先檢查他們是否已簽署 PSF 貢獻者許可協議。如果未簽署，則要求他們在繼續合併更改之前簽署一份。
2. 將更改本地應用到主 CPython 倉庫的當前副本（更改通常會首先在 bugs.python.org 上作為補丁討論和審查，但對於直接來自核心開發者的更改，此步驟目前不被認為是強制性的）。
3. 在本地執行測試套件，至少執行 make test 或 ./python -m test（根據系統規格，在預設配置下需要幾分鐘，但如果啟用所有可選資源，例如外部網路訪問，則需要更長時間）。
4. 執行 make patchcheck 以修復任何空格問題，並提醒可能需要的其他更改（例如更新 Misc/ACKS 或在 Misc/NEWS 中新增條目）
5. 提交更改並將其推送到主倉庫。如果 hg 指示這將在遠端倉庫中建立新的頭部，則執行 hg pull --rebase（或等效命令）。理論上，此時應該重新執行測試，但跳過這一步是_非常_誘人的。
6. 推送後，監視穩定構建機器人，檢視您的更改是否引入了任何新故障。特別是，POSIX 系統上的開發者經常會破壞 Windows 構建機器人，反之亦然。不那麼常見的是，Linux 或 Mac OS X 上的開發者可能會破壞其他 POSIX 系統。

在 Windows 上所需的步驟類似，但使用的具體命令會有所不同。

錯誤修復的工作流程非但沒有更簡單，反而比新功能的工作流程_更_複雜！新功能的優勢在於只應用於 default 分支，而錯誤修復還需要考慮包含在維護分支中。

• 如果某個錯誤修復適用於 Python 2.7，那麼它也會單獨應用於 2.7 分支，該分支在 Mercurial 中作為獨立 HEAD 維護。
• 如果某個錯誤修復適用於當前的 3.x 維護版本，那麼它首先應用於維護分支，然後向前合併到預設分支。兩個分支同時推送到 hg.python.org。

文件補丁比功能補丁簡單，但也沒有簡單多少——主要好處是隻需要檢查文件構建是否成功，而不是執行測試套件。

我估計，即使一切順利，我也至少需要 20-30 分鐘才能提交一個能幹淨應用的錯誤修復補丁。考慮到其中幾項任務應該可以自動化，我不認為我們目前的做法有效地利用了稀缺的核心開發者資源。

當前的工作流程中存在許多令人沮喪的地方，這些直接導致了一些不良的開發實踐。

• 大部分開銷是按每個應用的補丁產生的。這鼓勵了大型提交，而不是小的獨立更改。提交一個 500 行功能所需的時間與提交一個 1 行錯誤修復所需的時間基本相同——大型更改所需的額外時間出現在任何先前的審查中，而不是作為提交過程的一部分。
• 修復錯誤的額外開銷進一步鼓勵了開發者轉而開發新功能，而新功能本身就_更_有趣——它們不需要工作流上的困難來推波助瀾！
• 在 bugs.python.org 上進行事先審查是_額外_的工作，這促使直接提交更改，從而增加了對 python-checkins 郵件列表上事後審查的依賴。
• 跟蹤器上那些完整、正確且準備好合併的補丁，仍可能長時間無人問津，等待核心開發者有時間進行合併。
• 推送衝突的風險（尤其是在推送合併的錯誤修復時）促使開發者跳過完整的本地測試執行（尤其是在遇到一次推送衝突之後），從而增加了破壞構建機器人的可能性。
• 構建機器人有時會長時間處於紅色狀態，這會在本地測試執行中引入錯誤，也意味著它們有時無法可靠地指示補丁是否引入了跨平臺問題。
• 會議後的開發衝刺是一場噩夢，因為它們會陷入推送衝突的泥潭。人們很想直接把補丁留在跟蹤器上，直到衝刺結束再嘗試清理。

核心開發者也有很多犯錯的機會，這些錯誤會給其他人帶來不便，包括管理 Mercurial 分支以及在無法及時修復的情況下破壞構建機器人。這既讓現有的核心開發團隊在授予新開發者提交許可權時變得謹慎，也讓這些新開發者在使用他們提升的許可權時變得謹慎。

還有一些偶然的煩惱（例如保持 NEWS 檔案更新），作為本提案的一部分，也必然會得到解決。

志願者驅動的開源專案最關鍵的資源之一是其貢獻者的情感能量。當前的程式碼合併方法在這方面對任何人來說表現都不佳。

• 對於核心開發者來說，錯誤修復的分支管理很精細，很容易出錯。NEWS 檔案衝突和嘗試上傳更改時的推送競爭增加了惱怒，而我們大多數人並沒有為此付出時間（對於那些為此付出時間的人來說，為 CPython 貢獻可能只是我們眾多職責之一）。我們花在實際合併更改上的時間，就是我們沒有花在編寫額外更改、撰寫或更新文件或審查他人貢獻上的時間。
• 紅色的構建機器人給其他開發者（因為本地測試失敗可能_並非_由於該開發者的任何操作）、釋出經理（因為他們可能需要在釋出前尋求協助清理測試失敗）以及開發者本身帶來了困難（因為它產生了巨大的壓力，要求我們_立即_修復我們無意中引入的任何故障，而不是在更方便的時間，以及如果 hg annotate 不足以識別新故障的來源，則可能使 hg bisect 更難使用）。
• 對於其他貢獻者來說，核心開發者花費時間實際合併更改，就意味著該開發者沒有在問題跟蹤器上審查和討論補丁，也沒有以其他方式幫助他人有效貢獻。對於習慣於開發者只需在專案的 CI 系統中自動測試過的拉取請求上點選“合併”的簡單流程的貢獻者來說，尤其令人沮喪（這在 GitHub 和 BitBucket 等網站上是一種常見的工作流程），或者合併過程中的事後審查部分是完全自動化的（OpenStack 就是這種情況）。

現有工具

以下工具目前用於管理 CPython 核心開發工作流的各個部分。

• Mercurial (hg.python.org) 用於版本控制
• Roundup (bugs.python.org) 用於問題跟蹤
• Rietveld（也託管在 bugs.python.org 上）用於程式碼審查
• Buildbot (buildbot.python.org) 用於自動化測試

本提案建議用 PEP 474 中提議的基於 Kallithea 的 forge.python.org 服務取代 Rietveld 進行程式碼審查，該服務功能更完善。Guido 曾表示，最初的 Rietveld 實現主要旨在作為 Google App Engine 的公共演示應用程式，而改用 Kallithea 將解決在使用 Roundup 上的補丁檔案以及整合 Rietveld 例項中的相關審查時出現的識別預期目標分支的一些問題。

它還建議新增新工具以自動化工作流程的更多部分，並對現有工具進行批判性審查，以檢視哪些工具（如果有的話）可能被替換。

提案

本提案的實質是 CPython 旨在採用“核心審查者”開發模式，類似於 OpenStack 專案所使用的模式。

CPython 核心開發團隊遇到的工作流程問題並非獨有。OpenStack 基礎設施團隊設計了一套完善的自動化工作流程，旨在確保：

• 一旦補丁經過審查，只有當自動化測試在合併前失敗時，才需要進一步的開發者參與。
• 補丁在未針對分支當前狀態進行測試的情況下絕不合並。
• 主開發分支始終保持綠色。未透過自動化測試的補丁不會被合併。

如果核心開發者希望在合併前調整補丁，他們會從審查工具中下載它，修改並_將其重新上傳到審查工具_，而不是直接推送到原始碼倉庫。

這個工作流程的核心是使用一個名為 Zuul 的工具實現的，這是一個專門為 OpenStack 專案建立的 Python web 服務，但其設計有意採用了基於外掛的觸發器和作業系統，以便更容易地適應替代的程式碼審查系統、問題跟蹤器和 CI 系統。OpenStack 基礎設施團隊的 James Blair 在 linux.conf.au 2014 上提供了對 Zuul 的精彩概述。

雖然 Zuul 處理 OpenStack 的多種工作流程，但本 PEP 感興趣的特定工作流程是“合併門控”工作流程。

對於此工作流程，Zuul 被配置為監控 Gerrit 程式碼審查系統，以查詢已標記為“已批准”的補丁。一旦發現此類補丁，Zuul 就會將其取走，並將其合併到“候選合併”佇列中。然後，它會建立一系列在 Jenkins 中並行執行的測試執行（以便在完整測試執行需要將近一個小時的情況下，每天允許超過 24 次提交），並在通過後（以及佇列中所有在其前面的候選合併通過後）合併。如果補丁測試失敗，Zuul 會將其從佇列中取出，取消該補丁之後佇列中的任何測試執行，並在不包含失敗補丁的情況下重新構建佇列。

如果開發者檢視合併失敗的測試，並確定是由於間歇性故障，他們可以重新提交補丁以再次嘗試合併。

為了使此過程適應 CPython，應該可以實現 Zuul 監控 Kallithea 中已批准的拉取請求（這可能需要在 Kallithea 中新增一項功能），將其提交給 Buildbot 以在穩定的 Buildbot 上進行測試，然後適當地在 Mercurial 中合併更改。這個想法帶來了一些技術挑戰，下面將有專門的章節討論。

對於 CPython，我不認為我們需要利用 Zuul 並行執行測試的能力（至少在初始迭代中不需要——如果我們達到了合併門控系統對補丁進行序列測試成為主要瓶頸，而不是我們缺乏足夠的人力來審查和批准補丁的程度，那將是非常好的一天）。

然而，合併佇列本身是一個非常強大的概念，應該能直接解決上述“理由”中描述的幾個問題。

延期提案

OpenStack 團隊還使用 Zuul 協調其他一些活動：

• 針對釋出到 Gerrit 的補丁執行初步的“檢查”測試。
• 合併更改時建立更新的釋出工件並重新發布文件。
• 彈性重新檢查功能，它結合垃圾郵件過濾器使用 ElasticSearch 來監控測試輸出，並建議可能導致測試失敗的具體間歇性故障，而無需使用者手動搜尋日誌。

雖然這些是未來值得探索的可能性（也是我認為尋求與 OpenStack 基礎設施團隊更緊密協調可能帶來的好處之一），但我認為它們提供的根本性工作流改進不如合併門控那麼顯著。

然而，如果我們發現門控中出現太多間歇性測試失敗問題，那麼可能需要將“彈性重新檢查”功能作為初始部署的一部分進行考慮。

建議變體

特里·裡迪建議進行初步篩選，專門尋找已批准的僅文件補丁（在 4000 多個開放的 CPython 問題中，大約有 700 個是純文件更新）。這種方法將避免與不穩定測試和跨平臺測試相關的幾個問題，同時仍允許解決其他自動化流程（例如如何將補丁推入合併佇列）。

這種方法的關鍵缺點是 Zuul 無法像通常預期的那樣完全控制合併過程，因此可能需要額外的協調。

如果初始部署的測試可靠性問題超出預期，這種方法可能值得作為備用選項。

還可以調整合並門控標準，使其在檢測到補丁未修改“Docs”樹以外的任何檔案時，不執行測試套件，而只檢查文件是否構建成功且沒有錯誤。

作為另一種替代方案，將部分文件（例如教程和 HOWTO 指南）從主原始碼倉庫中移出，並使用 PEP 474 中描述的更簡單的基於拉取請求的模型進行管理可能更為合理。

預期收益

本提案的好處最直接地體現在核心開發團隊上。首先，這意味著一旦我們在更新的程式碼審查系統中將補丁標記為“已批准”，我們_通常就完成了_。實際應用補丁、執行測試並將其合併到 Mercurial 的額外 20-30 分鐘（或更長時間）都將由 Zuul 協調。推送衝突也將成為過去——如果大量核心開發者在衝刺中批准補丁，那隻會意味著 Zuul 中的佇列變深，而不是開發者在嘗試合併更改時沮喪地失敗。測試失敗仍然會發生，但它們會導致受影響的補丁從合併佇列中移除，而不是破壞主倉庫中的程式碼。

由於大部分時間投入已轉移到審查流程，這也鼓勵了“為可審查性而開發”——更小、更容易審查的補丁，因為多次執行測試的開銷將由 Zuul 而非核心開發者承擔。

然而，從核心開發團隊中消除這種時間消耗也應該改善其他貢獻者進行 CPython 開發的體驗，因為它消除了補丁“被遺漏”的幾種可能性，並增加了核心開發者可用於審查貢獻補丁的時間。

對其他貢獻者的另一個好處是，當一個主要面向新貢獻者的衝刺只有一名核心開發者在場時（例如過去幾年 PyCon AU 的衝刺），合併佇列將允許該開發者將更多時間集中在審查補丁和幫助衝刺中的其他貢獻者上，因為接受補丁進行合併現在只需在 Kallithea UI 中單擊一下，而不是目前相對耗時的過程。即使有多名核心開發者在場，讓他們將時間和精力花在與衝刺中其他參與者的互動上，也比花在那些足夠機械化、計算機能夠（也應該）處理的事情上要好。

透過自動化消除大部分在提交更改時可能犯錯的方式，當貢獻者被提名為核心開發者時，需要學習的新東西也大大減少了。這應該會帶來雙重好處，既能讓現有核心開發者更放心地授予額外的責任級別，也能讓新貢獻者更放心地行使這些責任。

最後，CPython 中更穩定的預設分支使得其他 Python 專案能夠直接針對主倉庫進行持續整合，而無需等到新版本的釋出候選階段。目前，建立這樣的系統並不是特別有吸引力，因為它需要一個額外的機制來等待 CPython 自己的 Buildbot 佇列指示構建處於可用狀態。有了提議的合併門控系統，主幹始終保持可用。

技術挑戰

將 Zuul 從 OpenStack 基礎設施適配到 CPython 基礎設施至少需要開發額外的 Zuul 觸發器和動作外掛，並可能需要對我們現有的一些工具進行額外開發。

社會挑戰

這裡主要的社會挑戰是讓核心開發團隊改變他們的做法。然而，該提案所自動化的那些繁瑣但必要的步驟，應該會為現有開發者採納這個想法創造強大的動力。

我相信可能需要三個具體功能來確保現有開發者確信此工作流自動化沒有負面影響：

• 只需一位核心開發者的批准即可合併補丁。將來可以重新審視這一點，但我們應在初始推廣階段保持現狀。
• 明確宣告核心開發者可以自由批准自己的補丁，但在釋出候選階段除外。這在將來可以重新審視，但我們應該在初始推廣階段保持現狀。
• 確保至少釋出經理擁有“立即合併”功能，允許他們強制將特定補丁置於合併佇列的頭部。為此，使用單獨的克隆進行釋出準備可能就足夠了。從長遠來看，自動合併門控也可能允許更自動化的釋出工件準備。

實際挑戰

PSF 執行其自己的直接和間接贊助的工作流基礎設施，主要是由於過去經歷過免費提供給公眾的基礎設施效能不可接受的糟糕和缺乏靈活性。CPython 開發最初託管在 SourceForge 上，當 SF 在提供 Subversion 支援方面速度慢且 CVS 存在效能問題時（參見 PEP 347），原始碼控制遷移到自託管；而問題跟蹤後來遷移到專用贊助託管（來自 Upfront Systems）上的開源 Roundup 問題跟蹤器，這是由於 SF 效能問題和當時 SF 跟蹤器普遍可用性問題的綜合原因（新跟蹤器選擇的結果和過程記錄在 python.org wiki 上，而不是在 PEP 中）。

因此，涉及“SourceForge 可用性和可靠性問題，第二輪”的提案將面臨至少一部分 CPython 核心開發團隊成員（包括本 PEP 的作者）的強烈反對。本提案尊重這一歷史，僅推薦那些可用於自託管作為贊助或 PSF 資助基礎設施的工具，並且這些工具也是開源 Python 專案，可以根據 CPython 核心開發團隊的需求進行定製。

然而，為了使本提案取得成功（如果獲得透過），我們需要了解如何進行必要的配置、定製、整合和部署工作。

上次為 CPython 支援基礎設施新增新元件（speed.python.org）的嘗試不幸因核心開發者和 PSF 董事會成員缺乏時間來推動專案，以及難以讓其他人迅速掌握並領導這項活動而擱淺（HP 捐贈給該專案的硬體目前用於支援 PyPy，但這種情況突顯了依賴志願者工作且他們有許多其他更高優先順序需求來完成專案所面臨的一些挑戰）。

即使是最終成功的過去專案，例如從 CVS 到 Subversion，再從 Subversion 到 Mercurial 的原始碼控制遷移，從 SourceForge 到 Roundup 的問題跟蹤器遷移，Roundup 和 Rietveld 之間的程式碼審查整合，以及 Buildbot 持續整合艦隊的引入，都經歷了漫長的時間，因為志願者們努力克服了涉及的眾多技術和社會挑戰。

幸運的是，由於本提案和 PEP 474 的幾個方面與 Red Hat 的 Beaker 開源硬體整合測試系統以及其他與工作相關的專案中正在考慮的各種工作流程改進相吻合，我已安排每週投入約 1 天時間用於 CPython 基礎設施專案。

連同 Rackspace 目前對維護 pypi.python.org 基礎設施的貢獻，我個人認為這種安排表明瞭 CPython 再分發商和主要使用者之間更普遍的認識，即透過直接貢獻開發時間來幫助維持上游基礎設施的價值，而不是期望志願者貢獻者完全利用業餘時間維護該基礎設施，或透過 PSF 間接資助（這將涉及額外的管理開銷）。我認為這是一個積極的趨勢，我將盡我所能繼續鼓勵它。

開放問題

PEP 中的一切。我們是否要採用合併門控和 Zuul？我們如何解決各種技術挑戰？Kallithea 和 Zuul 開發社群是否願意進行成功所需的那種協作？

雖然我已經安排了一些自己的工作時間來做這件事，但我們是否要向 OpenStack 基金會尋求額外幫助，因為我們是 OpenStack 本身的關鍵依賴項，Zuul 是 OpenStack 基礎設施團隊的建立，而且 OpenStack 可用的開發資源目前遠遠超過 CPython？

為 Python 再分發商和主要使用者工作的其他相關人員是否也能向其上級提出商業理由，以便投入開發時間來支援這項工作？

下一步

如果實施，這將是基於 Kallithea 的 forge.python.org 提案 PEP 474 的後續專案。有關目前正在進行的討論、審查和概念驗證試點過程的更多詳情，請參閱該 PEP。

致謝

感謝 Jesse Noller、Alex Gaynor 和 James Blair 對本提案初稿提供了寶貴反饋，以及 James 和 Monty Taylor 在初稿釋出後提供了額外的技術反饋。

感謝 Bradley Kuhn、Mads Kiellerich 和其他 Kallithea 開發者就 PEP 474 進行的討論，這些討論促使本提案進行了重大修訂，改為基於 Kallithea 作為審查元件，而非現有 Rietveld 安裝。

版權

本文件已置於公共領域。