Python將遷移到GitHub
2016-01-25 14:08:48 來源:Sergio De Simone ,譯者 適兕 評論:0 點擊:
Python目前的維護者,Brett Cannon,日前在Python的核心工作流郵件列表中宣布了Python將遷移到Github中,在與InfoQ的對話中,Cannon解釋了決定此次遷移花了超過一年的時間,當初主要的考慮有如下三個備選方案:
最后到決定是選擇了GitHub,主要歸結為以下三個方面的原因:
- GitHub和GitLab在功能方面基本差不多;但是,Cannon這里特別提到,GitLab的開源與否根本就不是決定性的因素。
- 活躍的開發者均熟悉Github,無論是核心開發者還是外圍的貢獻者。另外就是,雖然有一些開發者明確的反對遷移到GitHub,但是沒有一個說如果社區就這么決定了就沒有人使用Github了。
- Guido van Rossum偏愛Github,Cannon考慮到盡管現在Rossum只是偶爾貢獻一下,但他的影響力仍在,為了避免潛在的沖突,應當考慮Rossum的感受。
Cannon向InfoQ談到他是如何做這個決定的:
基本上我這次的所作的決策過程和原來做過的兩次沒有太大的不同,過程都是這樣的:我向PEP請求關于問題的可能的解決辦法,基于所提出的議題來進行討論(盡管討論通常都是流于形式的,但是PEP會自始自終都保留詳細記錄,有最新的建議一般都會通知到),制訂各種期限,比如測試實例這樣的,到那時,當我要做出決策的時候,我所基于的素材就非常的豐富了。
這里值得一題的是Python使用GitHub,僅用于其代碼托管和代碼審核的支持,這也就意味著Python的缺陷跟蹤和維基百科不會遷移到GitHub上。
Cannon還講過Python的核心開發者們彼此之間也是爭論的不可開交。Stefan Krah所表達的觀點其實是代表了開發者當中傾向于使用GitLab的人們,為此,Cannon專門進行了回復,并收到了很多未抄送給郵件列表的私聊回復,均回答了假定GitHub是首選的話大家是否會停止提交代碼?他還補充到,在他看來無論是遷移到GitHub或者是其它的倉庫都會有一小部分人的不適應,但必須要妥善處理。
InfoQ借機采訪了Brett Cannon,希望更加深入的了解到此次決定所能帶來的好處,在整個流程中目前處于何種地步。等等。
你能解釋下Python和Python社區遷移到Github有何好處嗎?
我目前正在寫的一個PEP的草稿可以解答一部分,但是我們所期望的好處是可以做到更快速的補丁審核以及人們能夠更加容易的參與到社區(真正的關鍵還是前者,但后者屬于錦上添花)。希望是所有的工具都是或可以是圍繞著GitHub所構建,能夠做到為Python開發團隊過去需要手動去做的大量的工作均替代為自動化,減少花時間去審核補丁的時間,從而提高生產效率。(目前我們最大的問題就是在缺陷跟蹤上對于外來貢獻者特別的不好,甚至讓他們非常的不爽)。更何況不論是開發團隊還是更為廣泛的開源社區均對GitHub熟悉有加,而且我希望的是讓所有人參與其中能夠更加的快速和方便。
目前的狀態是什么?下一步將會做什么?
說到狀態,我是在2016年1月1日對Python的開發遷移到GitHub上這個決定的,現在的話我正在撰寫關于我們各個代碼倉庫遷移所需要的所有步驟的PEP(在上一個問題的回答中我給出的鏈接)。一旦在我們的核心工作流郵件列表中達成共識,且PEP會更加的完善、突出一些細節。在那之后,我們就會開始我們的工作。
至于具體的接下來的工作,他們要做的就是解決掉那些個會妨礙代碼倉庫遷移的“攔路虎”。因為我們遷移倉庫所花費的困難是取決于他們所需要的工具,我希望是首先解決掉所有倉庫的通用問題,然后再根據具體的倉庫問題具體的解決。
你在公告中提到郵件列表中仍然有一些爭論存在,你希望以何種方式來結束這場討論?
你指的是在我發表過決定之后在核心工作流郵件列表中的討論吧!我對此結果非常的滿意。雖然有一些人因為GitLab擁有一個開源的版本就愿意去選擇它,但是所有人都理解我為何做出如此的決定,而且支持我的堅持。大家還是對此次遷移持積極態度的,而且利用此機會讓我們的開發平臺盡可能的保持平臺無關性,在未來能夠不懈的追求更加的簡單(這一定能夠實現,自從我成為核心開發者之后,這算是第三次改動了,而且Python到今天已經走過了第25個年頭,依然保持強勁的勢頭,當然,在接下來的幾年,我們是不會再做平臺的變換的了)。
開源項目近期往Github上遷移似乎漸漸的增多,你是否有過擔心,如其它人那樣認為如此依托給一個商業公司是不靠譜的?你認為這會給Python帶來困擾嗎?
對于未來的平臺發生改變的情況還是非常擔心的(將來某個時候一定會發生)。但是我們將僅使用GitHub來托管代碼以及用來做代碼審核,前者是很容易找到替代產品,而后者的話,一旦關閉某個pull request歷史,其臨近的也就沒有什么價值了。也就是說,我們會對代碼審核的歷史做備份,那么我們一旦找到替代者,我們可以得到有效的代碼審核,因為審核歷史是有價值的,哪怕是直有一條接受的提交。如果GitHub不能提供開放的API給我們訪問數據以及提高壁壘的話,我們當初就不會考慮它。另外,諸如GitLab之類的平臺會提供一些工具讓你來替代GitHub,包括pull request都可以導入到他們的平臺,我們知道我們并不會失去什么,但是GitHub可以給我們最快的時間。還有就是我們的缺陷跟蹤系統不會遷移到GitHub上去,這就讓那些擔心失去控制的稍稍放松一些,縮小了一些改動的范圍。
相關熱詞搜索:python moving to github 語言 & 開發 github Python git 配置管理 動態語言 開放源代碼 源代碼
