Chromium項目文化

這是一個很好的嚮導，尤其是當你需要給自己的chromium代碼升級時會變的相當有用。

Chromium是一個開源的瀏覽器項目，官方網站列出了許多文檔。
官網最值得學習的地方：許多指引寫得非常細緻，能以老師教導學生的態度去敘述如何工作，而不是爲了寫文檔而寫文檔，例如“不要害怕問問題，總有人會在IRC上幫到你”。多數文章寫得很好很凝練，沒法抽取主要信息，全文翻譯又太耗時，不如直接看原文。所以只需要篩選出有用的信息，而不用自己總結什麼。雖然一些文檔會偏舊，但勝在齊全，特別是工作規範類的文檔，能爲團隊協作做出良好的引導。
文檔主要分類如下：
1. 開發相關：如何checkout、編譯、調試、開分支、提交代碼、發review和review指引、成爲committer及其職責說明、學習路徑指引、開發工具使用指引、以功能劃分模塊的架構設計、代碼規範。
2. 測試相關：報bug指南、bug處理流程、bug系統的使用、各種自動化測試系統的使用。
3. 交流：通訊工具、信息發佈blog、術語表、wiki、文檔索引、在線的代碼查看和搜索站點。
4. 項目管理：宗旨、發佈日程、設計理念、演進方向、開發計劃管理。

開發相關：
對開發者，有一個文檔彙總的頁面http://dev.chromium.org/developers，頁面下方是全部文檔的索引。
Life of a Chromium Developer。PPT總結。
代碼學習路徑指引。
需求點狀態。在這裏能看出開發的方向和進度。（各種方向的都有，很難自己總結，偏H5的多）。
信息發佈的blog。
術語表。
用Sublime Text編輯代碼。

準備好代碼：
- 必須遵守代碼規範。
- 必須經過測試，通常是單元測試。代碼的量級合理。
- 大量的代碼無法很快review完。
運行單元測試和UI測試確保你沒搞壞任何東西。或請其他人提交到try server。
個人Contributor和公司Contributor需要分別籤協議。簽過後會把聯繫方式加到AUTHORS文件裏。（從這個AUTHORS文件發現總共有435個獨立committer和11家公司）
開發：
先開分支，並準備change list（CL）。
git checkout -b mychange origin/master
echo "This describes the goat teleporter." > GOATS
git add GOATS
git commit
然後提交到Rietveld做review。change list有模板。

commit流程：
先提交到try server，等所有測試變綠。提交時，確保：IRC在線，不離開座位。
review系統。這系統是開源項目Rietveld做的。
external目錄的代碼不屬於Chromium項目，需要對應項目的committer權限，按對應的方式去寫代碼和提交。

Review相關：
除了找OWNERS文件來找到reviewer，還可以用svn blame或git blame來查看誰編輯過此文件。
由於Chromium是全球開源項目，開發者之間有時差，review過程可能持續24-48小時。減少這一影響的建議是review的評價更細緻。
Review通過後，可以在Rietveld選擇commit或用命令行git cl set_commit，會先提交到commit_queue，這是非committer提交代碼的方式。committer還是可以直接提交代碼的，但不鼓勵這樣做，因爲沒經過tests。reviewer對非committer發起的review，有一個Checklist指引。

有提交權限的稱爲committer，沒有權限但通過別的方式貢獻代碼的叫contributor。
成爲committer：
簡單來說就是提交10到20個有價值的patch並請至少3個以上不同的人review過，然後請某人提名你作爲committer候選人並獲取支持。
需要證明你自己：
- 致力於對此project做貢獻（10個以上good patch需要非常多的時間）
- 能和團隊協作得很好
- 瞭解團隊如何運作（規則，測試和review流程等）
- 瞭解project的代碼基礎和編碼風格
- 寫出好的代碼
請一個committer通過郵件給[email protected]來提名你，內容包括：
- 你的名字
- 你的email地址。需要獲取@chromium.org的郵箱
- 解釋爲什麼你必須成爲committer
- 你提交的patch的revisions列表
還需要另外兩個committer支持你的提名。如果5個工作日內沒人反對，就通過了。如果有人反對或需要更多信息，committer們會討論並在5個工作日內達成一致意見。如果問題還不能解決，將會以投票來解決。通常反對原因是這兩個：需要提交更多patch；沒有足夠的人熟悉你的工作。
通過後，會獲得SVN或Git的寫權限，並添加到郵件組[email protected]裏。
不需要做額外的事情來維持committer身份。

Commit Queue：
這是一個自動化工具幫助提交Rietveld的變更代碼。在這之前，committer需要在本地運行腳本來到try server上跑集成測試。工作原理是去codereview系統獲取closed和待commit的任務，在隊列中不斷髮起try server的測試。其中有一些更智能化的設計，暫沒必要深入研究了。

如果想增加一個新功能，可以先去討論組發帖。如果是基於已有的代碼做修改，可去每個目錄找OWNERS文件，找到owner做討論。
bug系統裏不是所有bug都已分派人員去解決，如果你感興趣可以請求這個bug讓你解。

DevTools開發工具，歡迎對這塊貢獻代碼，開發工具和寫文檔。

測試相關：
獲取bug編輯權限：
任何人都可以報告bug和添加評論，但增加標籤、標記重複、改變狀態則需要額外的權限。

提交patch前需要在try server先通過測試，如果不想其他人幫忙try，可以單獨申請try的權限。可以先獲取@chromium.org郵箱然後去填寫申請表格，或請合作的人發郵件去[email protected]申請。

Try Server：
是一個標準的buildbot和一系列的slave。由此得到LKGR（Last Known Good Revision），會公佈在http://chromium-status.appspot.com/lkgr。

bug系統：
bug列表：https://code.google.com/p/chromium/issues/list。此係統是自己開發的，列表帶有ID、優先級、發現bug的版本、迭代記錄、解決的channel（穩定版或beta版）、分類、狀態、owner、概要和標籤、操作系統、修改日期。頁面有鏈接轉向：報bug嚮導、高級搜索，搜索提示（技巧，如特別的關鍵字，條件搜索，附件搜索等)，自行關注某類label（有此類bug會收到email）。
報bug的頁面：http://code.google.com/p/chromium/issues/entry
Mac & Linux報bug指南：報bug的步驟、示範一個好的報告等。
報告崩潰bug的指南：Chrome可以打開上傳崩潰報告。設置->高級設置->勾上將使用情況統計信息和崩潰報告自動發送給 Google。然後可以打開chrome://crashes來查看崩潰ID。Android的手動收集：崩潰報告路徑在/data/data/$PACKAGE/cache/Crash\ Reports/。或者運行adb shell bugreport收集系統信息。
基本要求：
- 確保最新的代碼還有此bug
- 提供一個高級的問題描述
- 詳細的重現步驟
- 包含期望的行爲
- 確認其他瀏覽器是否有此bug
- 如果測試過程（如頁面）可以更簡化，做成簡單測試並附加到此bug裏
阻礙發佈的bug的處理指南。
報告無響應bug的指南。
報告安全bug的指南。
處理一個bug的指南。（非常細緻，值得一看學習如何編寫這類文檔）

交流：
交流方式：
討論組：區分專題，如常規討論組、插件(for Chromium）討論組、installable web apps(for Chromium)討論組、HTML5討論組等。

IRC（Internet Relay Chat）：即在線聊天室。主頻道：irc.freenode.net/#chromium

Wiki：多數是一些特殊的工作技巧。

有用的URLs：工作中常用的URL收集。
所有發佈版的情況：含版本、發佈日期、操作系統、對應的svn版本號、對應的webkit版本號，changelog等。
最近100個編譯ok的版本號。
在線的提交歷史記錄。
committer名錄。
在線搜索代碼。

項目管理：
產品的宗旨：快速、安全、穩定、簡單（易用）。（從宗旨看，低資源消耗不是首要的）

不同的發佈版本稱爲不同的channel，五種：
Stable穩定版：經過測試team全面的測試，最大限度地避免崩潰和其他問題。差不多每兩到三週更新一個小版本，6個星期更新一個大版本。
beta版：有極小的風險，每週更新，比穩定版提前一個月發佈
Dev版：一或兩週更新，經過測試，但仍有bug，爲了讓用戶儘快體驗下個版本增加了什麼
Canary版：每日更新，未經過測試或使用，build出來就發佈。有自己的配置（文件）和設置選項，可以和其他channel的版本共存。用做報告崩潰和統計數據。
Other builds：Chromium有持續集成系統，可以到上面下載LGTM(look good to me自認爲是好的)的版本。

發佈日程和信息。

Blink: http://www.chromium.org/blink
一個開源項目也有使命：通過科技創新和好公民來改進開放的web。
從WebKit轉換到Blink的工作提示。
爲了推動Web Platform（可理解爲爲web開發者提供的平臺，簡單理解即開發標準）的發展，會增加新功能和刪除沒用的東西。API設計會向着透明、可靠、兼容性的方向發展。
增加新功能的流程：
1. 確定你的變更是否需要走這個流程：如果沒有影響開放到web的功能則不用；如果你的變更影響微不足道，只要reviewer不反對，可以不走此流程；如果你的變更無法在Blink上實現，請發email給Chromium團隊。
2. 在chromestatus.com上新增一個項，跟蹤新功能的狀態，等待別人的反饋
3. 實現新功能
4. email給blink-dev，等待3個LGTM
5. 默認啓用此新功能
新API的review會舉行郵件討論。

Blink架構變更：
Chromium啓動時，初衷是儘量減少WebKit的改動，但現在可以做更大規模的改動，不需要擔心打斷WebKit的使用者。
一個變動是把iframe放到sandboxed進程中，因爲和其它WebKit的分支很不同，所以一直delay中。
另一個變動是改進網絡。因爲WebKit現有的網絡API多數爲了舊的Mac系統來設計，很陳舊，多bug。
最後是把整個DOM做到Javascript裏，這回大大加速Javascript訪問DOM，但也引起非常大的架構重寫，爲此也將不再考慮兼容JSC。其它的考慮：