Archive

Posts Tagged ‘Mozilla’

一个小bug引发的Mozilla开发过程改进, 堪称雷厉风行

November 28th, 2015 No comments

故事发生在2015年的感恩节前后, 起因很简单: Firefox的前端(UI部分)很多都是用JavaScript脚本写的, 9月份的时候一个开发人员无意间引入了一个bug, 这个bug的是类似”FooBar”错误写成了”Foobar”, 拼错了一个变量的大小写. 然后这个bug就进入了Mozilla的代码库, 潜伏了2个月多几天, 到了11月份的时候被发现, 并且修复了.

然后一个目睹了整个事件的(看着级别比较高的)员工就不能忍了, 拍案而起, 在 Firefox Dev 邮件列表公开喷这个事情, 表示”对于JS的代码检查我们可以做到更好”, 并且”对于Nightly地测试我们可以做得更好”.

这要是在一般的公司内部, 会在你上个厕所的时间内就演变成 Developer, Reviewer, QA 和 Manager 之间的撕逼大战, 妥妥的, 遵循”你不能说我有错否则就是骂我你针对我你是不是搞阴谋”这样的剧情发展下去. 但是这里是Mozilla, 于是立刻就就有(架构师级别的)人跳出来开始就这个需求 expand, 在bugzilla上开bug的开bug, 跳出来发表观点的发表观点, 跟这个需求有关系的Mozillian纷纷跳出来说自己做的 bug(s) 跟这个的关系, 可以先做A然后做B同时可以改过程C等等. 然后今天就看到, 一个现成的工具(ESLINT)已经可以在Mozilla的核心代码库上直接检查了, 被合并到了’mach’工具中. 一大批bugs被建立并开始fix[1].

这次事件的给我的感受是比较复杂和震撼的:

  • 作为 Level 1 的 “Mozillian”, 表示投身 Mozilla 这样的 highly-motivated 的社区真的会压力山大. 记得之前有一个 Firefox 开发人员(Level 3, not JS Team)特地写过一篇blog, 题目就叫”如何不要在Mozilla油尽灯枯(burnout)”[2]. 没有任何人会主动的压迫你做什么, 事实上 Mozilla 是 remote-friendly 的, 遵循一定程度的精英自治. 因此这需要你遵循着”能力越大, 责任越大”的原则不断的push自己. Mozilla 作为一个非常公开开放的组织, 基本上你所有的代码, 进展, 态度, 当然也包括过失, 个人威望, 都直接而且实时的曝光在网络上. 而全球各地的开发人员聚集在IRC上的时候, 如果你是足够重要的(比如到了Level 3), 几乎会一直都会有人在IRC问你问题, 在Bugzilla上让你Review, 让你回答疑问(needinfo), 或者让你bisect新暴露的bug. 这会让你像是被磁铁一样牢牢地吸住, 连轴转地贡献自己地力量. 如果你在IRC上被人ping了还不吭声, 或者消失了一段时间, 其他的人会自然而然的失望, 不再期待于你, 个人的 reputation 会有很大的影响.
  • Mozilla算是一个高度协作地组织, 虽然我没有听过说要实施敏捷开发之类地口号, 没有SCRUM之类地过程, 这个反应速度实在是快. 如果是我知道地国内软件开发团队, 估计要先吵一段时间, 然后更高级别地人出来拍板, 然后各个PM调整进度条, 然后不同部门之间继续吵架. 注意到这个过程地改进是牵涉到多个小team的, 没有上面那种”把个人热情和名望都绑定在自己的言行上”的精英自治体系, 估计Mozilla上面的大头早就burnout了.
  • 对事不对人, 跳出来说话地人素质都比较高. 相信这跟邮件列表公开与否并没有关系(Mozilla地组织模式比较难hide秘密), 就技术讨论技术改进的风格非常的高效[3]. 就我个人接触过的Mozillian而言, 都是非常的nice的. 我想即使有不nice或者很难打交道的人, 也会很快的被甄别出来, reputation 会掉得厉害, 会有人直接跳出来纠正或仲裁.
  • 发起这次过程改进的开发人员(Gijs), 在发出了两封过程改进的号召之后, 恰好卷入了另一个争议中. 作为前端(JS)开发, 他一次提交涉及平台(C++)修改, 代码包含了一个小的 memory leak, 提交之后立刻被一个(可能是平台的)C++开发发现, 并以此提议”JS语言在动C++代码的时候应该增加一个C++的开发来review”. 这个提议看着是有些”C++看不起JS”的味道[4], 但是同时, 那次commit确实有leak. 包括Gijs在内共有4个人参与了邮件讨论, 将两个问题拆分的非常清楚. 承认了错误的部分, 评估了影响程度, 同时也反驳了扩大的(带有偏见的)观点, 两个问题都有人站出来vouch. 这种应对能力, 我个人觉得对能力要求挺高的.[5]

[1] 我并没有关注fx-team那部分的bug, 平时关注放在了js-team这边, 具体多少个bugs并不了解. 感兴趣的同学可以自己查.

[2] Robert O’Callahan, “Avoiding Burnout” http://robert.ocallahan.org/2013/10/avoiding-burnout.html

[3] 当然, Mozilla也有因为bug处理过程长被人吐槽过. 最近的一个例子是 bug 322529, 再过2个月就整整10岁了! 😛

[4] 邮件标题是: “C++ code from JS engineers probably need additional review from C++ engineers”

[5] 另一方面, 这也体现出来了Mozilla内部确实也会存在不满地情绪, 并且会发泄出来.

WebAssembly 要开始并入 SpiderMonkey 了

November 13th, 2015 1 comment

从 BMO 上看到的(Bug 1224389), 速度真是快.

目前来看是要重构 OdinMonkey (JIT for asm.js), 共享后面的部分.

这样会不会又出现一个 xxxMonkey …

Project Candle: Mozilla 的低功耗改进计划

September 14th, 2015 No comments

在发起了性能改进计划(AreWeFastYet.com)和内存使用改善计划(AreWeSlimYet.com)之后,最近 Nicholas Nethercote 发起了新的功耗改进计划: Project Candle。

Nicholas Nethercote 是 Valgrind 的主要作者,背着顶会论文2000+次引用的光环 🙂

具体如何改进我还一窍不通,不知道低功耗怎么做的。Mozilla 已经建立了专门的 IRC 频道和邮件列表,具体可以看 Candle 的项目Wiki

Firefox Technical Architecture Group

September 11th, 2015 No comments

Dave Camp 一个月前在邮件列表中宣布了新的 Firefox 架构领导小组:

We don’t have a lot of people whose responsibility extends to the entire Firefox frontend. Most of us are focused on individual pieces of our large codebase. Meanwhile, we have a set of large technical challenges ahead of us. In particular, gofaster and figuring out what comes after XUL are going to be sweeping changes that affect large swaths of code.

We are asking Dave Townsend, Richard Newman, Rob Helmer, Mark Hammond, and Robert Strong to explicitly take over technical stewardship of the Firefox products. Their responsibilities will be:

* Document and build consensus around larger projects that affect Firefox products.
* Help resolve technical issues that cross functional areas of the project.
* Provide a point of consistent technical decision making.
* Be a point of contact for and coordinate cross-technology projects with other Mozilla groups such as Platform and Content Services.
* Be available to technical contributors for guidance, mentoring, etc.

This may look a lot like Module Ownership – this is no coincidence. Mark Finkle (as Firefox Mobile module owner) and I (as Firefox Desktop module owner) will be delegating a lot of the technical responsibility for those modules to that group. It may also remind some folks of the Super Reviewers. It’s similar to that in spirit (a group of people charged with a global view of the product) but not in mechanics (no sr? flags, and limited to the Firefox frontend modules).

This isn’t a permanent appointment. We’ve asked these people to help get us started working through the gofaster and deXULinisation initiatives, but we’ll cycle people in an out as events warrant. Nor do we expect these people to do it alone. We expect them to be working closely with all the engineers on the team.

Thanks to the Firefox Architects for stepping up.

 

现在差不多已经成型了:

https://wiki.mozilla.org/Firefox/Technical_Architecture_Group

不过目前在 Mozilla 之外还没有看到什么内容.

afl-fuzz vs. mozjs: 1st round.

August 13th, 2015 No comments

第一轮, 随机从 mozilla-central 的回归测试集中选择了几个js文件, 没有使用字典, 默认 afl-fuzz 配置.

结果: 一个 crash 都没有发现.

分析: 这个是合理的. 没有字典直接 Fuzz, 绝大部分都过不了前端的 Parser. (绝大部分的意思是我没有做统计, 直观猜测的)

afl-fuzz-vs-mozjs