【51CTO.com快譯】一直以來OpenStack都只是用Python編寫的，別的語言不是沒用只是用到的很少，核心部分幾乎都是Python，現有人提議讓Go語言也用在API服務方面。

在新版本Newton出爐的周期中，技術評估委員會接到了一份把Go語言作為OpenStack官方開發語言的提議。隨后進行了許多討論，這里不過多贅述過程，只是談談幾點討論的結果。

決議是暫時拒絕讓Go作為官方開發語言，但表示未來可以接著討論，我覺得Go被拒絕可能有以下幾方面的原因：

1.技術委員會成員擔心增加新的語言會對社區造成的影響。會不會對社區帶來分裂，會不會形成一個孤島，會不會給新入門的人帶來額外的門檻？
2.技術委員會的一些成員認為如今對社區中的一些方面缺乏信息，研究和工作。 Go代碼如何在整個社區中共享？ 認證怎么做？ 消息層怎么弄？ 如何產出版本？ 如何維持分支的穩定？
3.提議Go語言的團隊除了自己的項目以外根本就沒做過跨項目的任務，這不由得引起了懷疑，使得許多技術委員會的質疑是否能夠順利完成。

接受一門新的語言需要哪些條件呢？

我先聲明，我所說的不代表技術委員會而僅代表我個人意見，從而方便交流，好會讓整個社區的人發表意見，無論是同意或者反對我的想法。

討論期間我最關心的是***部分，主要是因為我覺得向“Big Tent”的遷移還沒完成。我也不知道怎么才會讓我覺得這遷移已經完成了，我能肯定的是我們在解決大的變化發生前需要解決的問題。

言歸正傳，我越來越喜歡給許多東西設定期望，尤其是一些能帶來改變的請求。把預期列出來之后，就能讓相關的人了解到他們正在向哪一個方向行進，并且找到改變可能會面臨的問題。

我對第二個問題遠沒有***個問題那么擔心。它會對參與討論這一變化的團隊表現出很強的承諾，因為這涉及到未來對社區所有成員使用和參考的基礎知識庫。我以為第二部分的工作可能有些超綱，但并不是這樣。通過研究怎么共享代碼，怎么測試代碼，怎么輸出代碼，怎么做認證庫等，我們在設定未來實際工作中需要用到的基礎的東西。

無論如何，我上面提到的“基礎的東西”是什么呢？我將在下面不太詳盡的列表中簡單談一下：

為新語言定義分享代碼和庫的方式

Oslo Team負責維護整個OpenStack社區需要經常用到的庫。這些庫包括消息庫（oslo.messaging）,i18n庫（oslo.i18n），數據庫層庫（oslo.db）等關鍵庫。

這些庫本身并不能讓Oslo組的人忙起來，它們是為了收集以前在社區中存在于許多項目中的重復性的公共代碼。這個代碼現在由Oslo移除，穩定和發布。

我覺得作為一個社區，這是無可避免的。一旦越來越多的項目使用相同的語言就會出現共享代碼的需求。 因此，我覺得我們需要更好地定義一個編程語言的代碼怎么在社區共享，這個挺重要的，哪怕是在編程語言被接受之前就很重要。

我覺得提前做一些事情不意味著將來沒事可做，我們都知道會有許多為預料到的事情和發生變化的事情，我覺得這些工作能涉及到大部分初始化的工作。

關于OpenStack基本服務的基本庫

這可能看起來像一個相當高的目標。雖然想搞清楚代碼如何共享是一個很困難的需求，但我認為這離OpenStack服務的***要求還差很遠。

集成在生態系統中的OpenStack服務至少需要以下任意一個庫：

•keystoneauth / keystone-client
•oslo.config
•oslo.db
•oslo.messaging

如果在使用數據庫或者消息隊列抽象庫的時候沒有任何消耗的話，很可能提供的抽象層是錯的，從而導致糟糕的API。從另一個方面說，認證層是幾乎所有OpenStack服務都會用到的部分，應該可以很方便使用才對，但這不是說這件事本身很簡單。

通過處理這些庫中的任何一個，都可以進行CI（自動測試系統）作業，通過這些作業來確保新項目的基礎設置是正確。

定義可交付項如何分布

OpenStack的發布過程幾乎完全是自動化的，發布過程中涉及到的所有可交付項都是由社區自動產出并由發布團隊來管理的。***，將每個交付項生成壓縮包。

目前使用Python編程語言（以及其他幾門編程語言）的時候 ，這些壓縮包因為只包含這些源代碼所以還很簡單。對于像Go這樣的編譯型語言，我們就得考慮壓縮包里要壓縮什么了，壓縮編譯過的二進制代碼嗎？是不是應該加入源代碼呢？如果要包含二進制代碼，是不是也應該考慮兩種不同的壓縮包呢？一個是二進制代碼，一個是源代碼。

維護穩定分支部分的工作怎么辦？

穩定的分支在社區經常被遺忘，維護這些穩定分支的團隊得到的感謝比較少。然而穩定分支的代碼運行在許多OpenStack云環境下，它們對于向后兼容的后端遷移修復非常關鍵。

每一門語言都有自己發布庫的方式，管理兼容性的方式。當為社區加入新的編程語言，與原有的其他團隊之間的合作是至關重要的。

為新的語言設置CI管道

還有就是與基礎設施組討論設置CI（自動測試系統）管道。

這個任務可能是許多工作的基礎。為了解決之前的許多任務，有必要設置CI（自動測試系統）作業，這涉及與基礎架構團隊協調。后者是至關重要的。 基礎設施團隊的參與對于添加任何新語言都至關重要，他們的反饋將在許多決策中發揮重要作用。

回顧一下為Python語言做的一些基礎工作，其實是大多數項目都需要做的事情。我希望致力于加入新語言的團隊可以做一些通用性的事情，為以后跨多個項目的時候使用。

比如會有以下幾方面的通用性工作：

•Lint checkers
•Doc builders
•Release Pipelines

要做的似乎還有很多

把上面提到的方方面面都做到的話的確需要許多人力和時間。不幸的是，涉及到的許多團隊真的騰不出手來做別的事情了，所以我覺得大部分工作將會由各組里多語言感興趣的人來貢獻出來的。無論如何，這些工作勢必耽誤每個團隊的工作時間，即使是大部分的研究，文檔和補丁都是由有興趣的團隊來自愿完成的。

整個社區花了多年時間讓Python處于目前的狀態。我不指望一個團隊工作一個禮拜來把新的語言代碼加入到已經用了六年的Python體系中。然而，機制已經建立，團隊也已經存在，在一起協作下，上述的問題可能會在合理的時間點得到解決。

我希望這是個循序漸進的過程，這就是我為什么強調需要經過以上幾個步驟的原因。人有流動性，即使是做過承諾有時候也不管用，我認為做這是最重要的是先做，然后在漸漸接受這門語言。

***，即使存在一個形式良好的添加新語言的過程，我仍然推薦優先使用Python而不是其他語言。這與語言偏好無關，只是與我們社區中現有的知識的傳播有關，我相信這種知識是無價的，將這些知識變成一種新的語言需要幾年時間，相比之下優化則是一個更容易的任務

創新對很多項目都很重要。我們也相信不可能永遠保持原樣，語言的變化，項目的興起，項目的消亡等等。加入新語言這回事兒也是社區變化 的一部分，我也希望OpenStack社區盡可能以***的方式擁抱變革。但我希望是以一種相對保守的方式。我相信本文中提到的這些任務將會幫助大家未來以更快、更安全的方式來增加新的語言。

當然，以上都是我的個人觀點，我現在越來越癡迷于明確預期。因此，我會起草并提交一份正式文檔到技術委員會。

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】