TensorFlow技術(shù)主管詳解：谷歌怎樣管理開源軟件（谷歌的tensorflow）

唐旭 編譯自 O’reilly

量子位 出品 | 公眾號 QbitAI

TensorFlow開源一年半以來，在GitHub上已經(jīng)有了820位貢獻者，close了5192條issue，還有1033條開放著。

同時，如果所有TensorFlow團隊成員都在GitHub上，而且屬于這個組織的話，它在Google內(nèi)部還有著一支75人的團隊。

一支人數(shù)不算少的全職團隊，是如何和數(shù)量眾多的開源貢獻者共同改進TensorFlow的呢？團隊的技術(shù)主管Pete Warden帶著深深的怨念，在O’reilly網(wǎng)站上發(fā)表文章，講述了他們是如何維護TensorFlow開源社區(qū)的。

以下內(nèi)容編譯自Warden的文章：

開源可不只是把代碼往GitHub上一扔，然后等著別人去用它就完事了。道理我都懂，可直到在谷歌成為TensorFlow團隊的一員，我才真正開了眼：要圍繞一個軟件打造出一個社區(qū)，要考慮的因素實在是太多太多了。

社區(qū)服務(wù)

當一個新的項目剛剛誕生時，在這個項目上能被稱作專家的，就只有那些把它寫出來的人。他們是僅有的能夠撰寫文檔和解答問題的人，同時，在對軟件的改進方面，他們也是最佳人選。

但結(jié)果，我們這類TensorFlow團隊中的核心成員反倒成為了項目成長的瓶頸。原因其實很簡單：我們沒法一次性把所有的事情都干完。是，我們確實知道該怎么騰出時間去寫代碼和文檔，因為這本來就是我們在谷歌日常工作的一部分；但要給一個超大社區(qū)里的眾多開發(fā)者解答問題，我們就有點懵比了——盡管我們知道，這對于項目的成功十分重要。

為了確保用戶們能夠得到他們需要的答案，核心工程團隊的全體成員開始輪班。每個人可以從以下幾個活里自己挑：處理Stack Overflow上帶有#tensorflow標簽的問題、檢查一遍GitHub上的pull request、給GitHub上的issue分類、同步外部和內(nèi)部代碼，或是找到那些失敗測試的原因。

如何分配這些工作由大伙自己決定。一般來講，如果每個工程師每次在一個特定領(lǐng)域負責一周的話， 我們勉強能讓這個輪班機制循環(huán)起來。這個機制實行之后，工程師們在他們值班當周的本職工作產(chǎn)出會大大降低——不過至少，每個人的工作被打斷的頻率降到了幾個月一次。

Pull request

我們將TensorFlow開源來讓社區(qū)能夠?qū)ζ湄暙I力量。到目前為止，已經(jīng)有超過400人從外部為我們貢獻了代碼，這其中既包括簡單的文檔修復，也包括像OS X的GPU支持、OpenCL的執(zhí)行、InfiniBand架構(gòu)下RDMA這樣的大輸血。首先，每次貢獻都會先從輪值核心工程師那里審一遍，以確定其是否真的管用；如果方案通過了最初的審核，我們會對它進行一組Jenkins測試來確保它不會引發(fā)任何故障；如果以上兩道程序都被通過了，輪值工程師會將方案交給另一位更加擅長相關(guān)領(lǐng)域的核心工程師再次進行審核。

在這一過程中，GitHub全新的精細代碼審核工具能夠為我們提供極大的幫助。而在它出現(xiàn)之前，要把所有人的評價都處理一遍是個十分痛苦的事情。當一名核心工程師與一位或更多的外部貢獻者協(xié)作時，經(jīng)常會有更大的pull request會被放入正在進行的工作中。直到每個人都滿意之后，PR就會被合并到GitHub上的樹頂，并在下一次同步運行時被合并進我們的內(nèi)部代碼庫。

代碼許可協(xié)議

作為自動化pull request程序的一部分，我們會將貢獻者的GitHub賬號與我們在谷歌開發(fā)者網(wǎng)站上的代碼許可協(xié)議（CLA）記錄相匹配，以確保每個外部貢獻者都拿到了CLA。我們的目標是是確保整個代碼庫都在阿帕奇2.0協(xié)議下準確無誤地得到了分配。當pull request的輪值工程師要對出現(xiàn)的全部問題進行歸類的時候，如果一個pull request的內(nèi)部關(guān)聯(lián)了多個郵箱，或是貢獻者需要以團體名義登錄，情況就會變得十分麻煩。

GitHub issue

GitHub用戶們已經(jīng)提交了5000多個關(guān)于TensorFlow的issue。對于有些人來說，這可能有點讓人沮喪；但對我來說，issue卻是個最棒的單位——因為它證明，人們是真的在使用這個軟件。

為了確保我們回應(yīng)了每個存檔的issue，輪值工程師會時刻查看新出現(xiàn)的信息并試著用標簽對其進行分類。如果那是個我們在短期內(nèi)無法在內(nèi)部搞定的問題，它就會被標記成“歡迎貢獻”；對于一些待處理的bug，我們會給他們按輕重緩急排個次序。這些天來，隨著一些外部用戶自己變成了某些問題的專家，越來越多的問題沒有借助我們的力量就被解決掉了，特別是在像Windows這類我們不會每天都用的平臺上。

如果一個issue沒能在社區(qū)中找到回答或修復，而它的優(yōu)先級又足夠高時，值班的人就會把它分配給團隊里一個了解此類問題的工程師。整個TensorFlow團隊的成員都有自己的GitHub賬號，因此我們可以用正常的GitHub issue追蹤器來實現(xiàn)任務(wù)的分配。我們確實考慮過把GitHub上提交的bug復制到我們的內(nèi)部系統(tǒng)中，但要為相同信息同步兩份副本，代價太高了。最后，我們讓工程師們除了留意內(nèi)部系統(tǒng)的追蹤器之外，也要打開郵件通知，以便能夠及時看到自己被分配了哪些GitHub上的問題。

Stack Overflow

Derek Murray是Stack Overflow值班小組的帶頭大哥，我覺得他回答問題的技能真是碉堡了。根據(jù)他的資料頁，這個人發(fā)過的帖子已經(jīng)觸及到了130萬人；為了讓我們能夠及時追蹤網(wǎng)站上那些帶有#TensorFlow標簽的問題，他還設(shè)法創(chuàng)建了一個RSS驅(qū)動的自動化電子表格。起初我們采取每周輪班制，但發(fā)現(xiàn)要處理問題的量對于一個人來講實在是太大了；后來我們采用了自動分配系統(tǒng)，情況變得好多了。

我本人就在這個輪班小組里，因此每天早上我瀏覽完自己的郵件后，我都會查看電子表格來弄清楚自己被分配到了哪些問題。很遺憾，我們沒法自己回答全部的問題，但每一個新進來的問題我們都會看。如果問題相對簡單的話，我們就自己把它答了。

當然，值班的工程師得頂?shù)奖粏栴}轟炸的前線去，但有些時候，回答某些問題需要更多的時間和專業(yè)知識。如果某個問題看上去能被答出來，但社區(qū)里卻沒看見站出來的英雄，我們就會研究一下代碼，扒一下團隊里有誰可能會對這個問題有些想法（通常是用git blame）。然后值班工程師就會向我們找到的人發(fā)封郵件，看其是否能提供一點幫助。

郵件列表

我們設(shè)置了一個郵件列表，但起初卻并不知道該怎么用它。我們很快就看出來，用這種方法來追蹤issue和回答一般問題有多辣雞。

后來，我們把它當成討論區(qū)來用，GitHub和Stackoverflow都不合適的話題，就發(fā)到郵件列表，但是在實際操作中我們發(fā)現(xiàn)，即便是架構(gòu)問題，用GitHub issue來討論也比郵件列表合適。

現(xiàn)在我們用這個郵件列表來發(fā)送信息和貼通知，還算是值得訂閱的。

代碼同步

和我聊過的許多人都對一件事表示十分吃驚——那就是在谷歌內(nèi)部，我們使用的代碼庫和我們在GitHub上所開放的幾乎完全相同。不過，兩者間還是存在一點區(qū)別的，比對谷歌專用基礎(chǔ)設(shè)施的支持是獨立的，路徑也和GitHub版不一樣，但同步的過程是完全機械的。我們至少每周推出一次內(nèi)部更新，更多時候是下載GitHub版本。

麻煩的是，我們要進行雙向同步。在GitHub的公共項目和我們的內(nèi)部版本上，有很多變動是同時發(fā)生的，而我們需要反反復復地把它們?nèi)窟M行合并。沒有現(xiàn)成的基礎(chǔ)架構(gòu)可供利用，因此我們使用了自己創(chuàng)造的一套Python腳本來處理這些問題。這些腳本能夠?qū)itHub上所有的變動拉進我們的內(nèi)部資源庫里，轉(zhuǎn)換所有的header path和其他細微的變化，將它們和最新內(nèi)部版代碼合并，并在內(nèi)部創(chuàng)建一個副本。隨后就可以進行另一個方向的同步了，我們會將所有的內(nèi)部代碼轉(zhuǎn)換成外部的格式，并用相同的腳本把這些結(jié)果合并到最新的GitHub版上。

對于內(nèi)部的修改，我們同樣會盡力讓每次check-in都呈現(xiàn)為單獨的git commit，同時把作者的GitHub賬號和解釋這些變動的評論包括在內(nèi)。我們在GitHub上有一個特別的“TensorFlow園丁”賬號來完成上述過程，一個內(nèi)部的commit被轉(zhuǎn)移到GitHub上之后，是這樣的：

要確保即使代碼變了，這個轉(zhuǎn)換流程依然有效，是很有挑戰(zhàn)性的。為了驗證這種有效性，我們要求把內(nèi)部代碼通過這個腳本轉(zhuǎn)換成外部版本，再轉(zhuǎn)換回來之后，和最初的內(nèi)部版一模一樣。在任何接觸到TensorFlow代碼庫的內(nèi)部更改上，我們都會運行這個測試，通不過測試的修改會被拒絕。

對于那些提交pull request的人，我們常常會提一些奇怪的變更要求，通常，這樣做的原因是我們必須確保他們的代碼能適用于這個同步流程。

Jenkins測試

因為要支持很多不同的平臺，我們希望有一個適用范圍很廣的測試工具。TensorFlow會在Linux、Windows、OS X、iOS、Android、Android Things、以及樹莓派上運行，同時我們還有為GPU準備的不同代碼路徑，包括CUDA和OpenCL支持、以及Bazel、cmake，和無格式makefile的構(gòu)建進程。

讓每一位開發(fā)者都在做了變更時手動把上面這些東西全都測試一遍，是不可能的。因此，我們有一套能在絕大部分支持平臺上運行的自動化測試系統(tǒng)，這些系統(tǒng)全都處于Jenkins自動化系統(tǒng)的控制之下。始終讓它們發(fā)揮作用也不是件容易事，因為總會存在操作系統(tǒng)更新、硬件問題以及其他一些與TensorFlow相關(guān)的問題能讓測試失敗。我們有一個工程師團隊，專門負責讓整個測試系統(tǒng)正常運行，這個團隊曾經(jīng)在系統(tǒng)出問題的時候救過我們很多次。因此在這方面的投入也是值得的。

開發(fā)者關(guān)系

在開源領(lǐng)域，我們在谷歌并不孤獨：我們曾經(jīng)在Kubernetes和“ 開源計劃辦公室”（Open Source Program Office）這樣的項目上學到過很多東西。有一支非常勤奮的開發(fā)者關(guān)系專家團隊協(xié)助我們處理這些事務(wù)，他們還承擔了很多圍繞文檔、代碼示例以及其他一些開發(fā)者經(jīng)驗方面問題而產(chǎn)生的體力活。我們的長期目標是，將關(guān)鍵的專業(yè)知識傳遞到核心開發(fā)者之外的范圍，以便更多的人能夠?qū)ι鐓^(qū)有所貢獻。

讓這些核心工程師在部分時間內(nèi)去承擔客戶服務(wù)工作的一大好處是，它給了我們關(guān)于用戶所遇到問題的直接洞見。參與客戶服務(wù)同樣驅(qū)動著我們?nèi)バ迯湍切┏Ｒ姷腷ug和補充文檔，因為它在減少工作量方面讓我們看見了直接的回報。

未來，我們希望將這項工作更廣泛地進行下去。同時，我們也設(shè)計了更多的“戰(zhàn)術(shù)指導手冊”以幫助人們處理常見任務(wù)。能有機會同如此多的外部開發(fā)者互動，我感覺十分幸運；我也希望，自己能對他們產(chǎn)生積極的影響，幫助他們用機器學習創(chuàng)造新的神奇應(yīng)用。

關(guān)于作者

Pete Warden是TensorFlow Mobile團隊技術(shù)主管。在加入Google之前，他曾任Jetpac CTO，該公司提供為手機和嵌入式設(shè)備而優(yōu)化的深度學習技術(shù)，2014年被Google收購。他還曾在蘋果工作，負責圖像處理的GPU優(yōu)化。（完）

招聘

量子位正在招募編輯記者、運營、產(chǎn)品等崗位，工作地點在北京中關(guān)村。相關(guān)細節(jié)，請在公眾號對話界面，回復：“招聘”。

One More Thing…

今天AI界還有哪些事值得關(guān)注？在量子位（QbitAI）公眾號會話界面回復“今天”，看我們?nèi)W(wǎng)搜羅的AI行業(yè)和研究動態(tài)。筆芯~