Chromium是一个开源的浏览器项目，官方网站列出了许多文档。
官网最值得学习的地方：许多指引写得非常细致，能以老师教导学生的态度去叙述如何工作，而不是为了写文档而写文档，例如“不要害怕问问题，总有人会在IRC上帮到你”。多数文章写得很好很凝练，没法抽取主要信息，全文翻译又太耗时，不如直接看原文。所以只需要筛选出有用的信息，而不用自己总结什么。虽然一些文档会偏旧，但胜在齐全，特别是工作规范类的文档，能为团队协作做出良好的引导。
文档主要分类如下：
1. 开发相关：如何checkout、编译、调试、开分支、提交代码、发review和review指引、成为committer及其职责说明、学习路径指引、开发工具使用指引、以功能划分模块的架构设计、代码规范。
2. 测试相关： 报bug指南、bug处理流程、bug系统的使用、各种自动化测试系统的使用。
3. 交流：通讯工具、信息发布blog、术语表、wifi、文档索引、在线的代码查看和搜索站点。
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。由此得到LKDR（Last Known Good Revision），会公布在http://chromium-status.appspot.com/lkgr。Try Server不是很适合需要快速迭代的UC。
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。其它的考虑：
- 让WebCore能多进程地记录历史（现在是单进程同步访问）
- 删除Widget树（这是Mac WebKit1的限制）
- 把WebCore拆成模块
- 尝试把DOM移入Javascript堆
- 增加多核的利用率（html解析、排版、js解析）
- 删除DOM的难理解的部分并做好向后兼容，优化性能和移除复杂性。
- 在Mac平台使用tcmalloc
- 尝试增量或并行排版
- 删除ScriptValue/ScriptState来解决内存泄露，因为只有一个js引擎了。
- 删除自定义的js bindings代码
- 实现DOM3 Events/UI Events
已实现的有： - 替换WebCore的platform代码为sandbox Platform API
- 建议更简单更严格的内部系统，不用再考虑2个js引擎
- 用WebIDL替代WebKitIDL
纯个人理解的多，不一定准确。很佩服的地方是：很多工具和系统，如果没有能拿过来就简单用的，干脆自己开发。这气魄相信很多工程师向往。
转载请注明出处：http://blog.csdn.net/hursing