首页 > 代码库 > Chromium项目文化

Chromium项目文化

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通过邮件给committers@chromium.org来提名你,内容包括: 
- 你的名字 
- 你的email地址。需要获取@chromium.org的邮箱 
- 解释为什么你必须成为committer 
- 你提交的patch的revisions列表 
还需要另外两个committer支持你的提名。如果5个工作日内没人反对,就通过了。如果有人反对或需要更多信息,committer们会讨论并在5个工作日内达成一致意见。如果问题还不能解决,将会以投票来解决。通常反对原因是这两个:需要提交更多patch;没有足够的人熟悉你的工作。 
通过后,会获得SVN或Git的写权限,并添加到邮件组committers@chromium.org里。 
不需要做额外的事情来维持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邮箱然后去填写申请表格,或请合作的人发邮件去committers@chromium.org申请。

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

Chromium项目文化