Skip to main content

6 posts tagged with "Mozilla"

View All Tags

· 5 min read

As our recent development focus shifting from Firefox OS to Firefox, we need to contribute to gecko repository directly instead of contributing to Gaia repository on Github. The most of the works are related to Javascript. The main change is the workflow and API difference.  In Gaia we work between Bugzilla and Github; In gecko, we have Bugzilla and mozReview.

Once you have setup the environment, the workflow could also be based on git(or hg), and most things are dealt automatically. Mozilla is a pretty open workplace so that I can share my workflow with the world. Here is a reference to how I did for per patch/weekly/per setup/one-time workflow.

Do it One time

To become a mozilla committer, read

Create Bugzilla API key and ssh key

Do at every Setup

You may check MDN as a start point, with Developer Guide and especially the source code page

I will do the setup flow every time I got a new laptop.

1. Update git

Use the PPA from the maintainers of git on Ubuntu:

$ sudo apt-add-repository ppa:git-core/ppa
$ sudo apt-get update
$ sudo apt-get install git

2. Install git-cinnabar

Gecko itself managed via mercurial, we need install git-cinnabar to help us deal with mercurial codebase via git.Check `

$ sudo apt-get install mercurial
$ git clone

Then set git-cinnabar into system PATH,

$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar
$ . ~/.bashrc

And do git cinnabar download to get the faster helper.

Then follow `Mozilla: A git workflow for Gecko development to checkout gecko via git.

Make sure you follow the Firefox build guide to setup Firefox build environment.

You can install style check related libraries via the following command:

$ ./mach eslint --setup

You may want install mozreview which improves the overall experience of review with Bugzilla

$ ./mach mercurial-setup

Will clone version-control-tools into ~/.mozbuild/version-control-tools. We need update system PATH

$ gedit ~/.bashrc
export PATH=$PATH:absolute_path_to/git-cinnabar:/path/to/.mozbuild/version-control-tools/git/commands
$ . ~/.bashrc
$ git config --global bz.username [email protected]
$ git config --global bz.apikey [your bugzilla key]
$ git config --global mozreview.nickname gasolin
$ git mozreview configure

Then, run bootstrap script to install required build environment,

$ ./mach bootstrap

Then, the most time-saving advice: setup mozconfig for artifact builds if possible. When you only work for front-end related work (non c++), Artifact build will download compiled platform code to save you lots of build time.

Weekly workflow

Previously build takes more time, I usually do the following command only twice a week if necessary. But now we can use artifact build, which is pretty fast and can be done many times a day.

We need update Gecko repository regularly:

$ git remote update

Then merge recent updates into current repo with

$ git rebase central/default

Checkout a new bug and then rebuild the stack,

$ ./mach build

The command will compile the whole gecko.

Per patch workflow

When I work on a new bug, I'll checkout a new branch (on mac)

$ git checkout -b bugxxxxxxx central/branches/default/tip

or (on Ubuntu)

$ git checkout -b bugxxxxxxx mozilla/central

Usually, the bug is focused on a component of gecko, such as browser/components/customizableui. To make .js/.jsm changes work, we don't need to rebuild gecko. But to make some C++ code or new test code works, we need to rebuild this part of source via

$ ./mach build browser/components/customizableui

Once we have some progress for the patch, we can test code via the command:

$ ./mach test browser/components/customizableui/test

You need to make sure you've followed the JS code style and CSS code style Do the eslint test before commit to make sure the patch does not contain some obvious syntax error.

$ ./mach eslint browser/components/customizableui/test

Once the patch is ready, commit it as normal git commit, with a structured syntax: Bug xxxxxxx - description. ;r=?reviewer_bugzilla_alias.

Then, use git mozreview command to push the commit onto Bugzilla for review.

$ git mozreview push

You can use try chooser to select test suites that run automatically on the test server. Treeherder is Mozilla's test server hosted on AWS (Amazon Web Service). Push code there and everyone will have the same base to validate if your code works well on anyone's computer.

The reference try script (credit from :Gijs) for browser/component is

try: -b od -t none -p win32,win64,macosx64,linux,linux64,linux64-asan -u mochitest-bc,mochitest-e10s-bc,marionette,marionette-e10s

You can manipulate the script based on what you need to test.

If you like to file a bug

  • Assign priorities when filing new bugs that you're going to work on in the component.


· 5 min read

Marissa Mayer 與起死回生的雅虎 一文中,可以看到雅虎工程師對自家 CEO 的讚美。其中一點提到雅虎內部有很多系統設計是與外界完全不一樣的,直到新 CEO 上任才放下使用多年的 YUI 而擁抱其他 Open Source 團隊維護的專案。

從樂觀的角度看:因為當初 Yahoo 工程師夠強(Douglas Crockford),覺得自己做的東西比別家的好,所以乾脆自己做。有這種「愛自幹」的精神,所以才會做出很多跟其他地方不一樣的東西,這是 feature。從反面看則是因為長期跟人家用的工具不一樣,所以沒辦法直接使用別人做的 Open source 工具,這也是 bug。

以前的 Yahoo「不擁抱其他 Open Source 團隊維護的專案」嗎?Yahoo 當然某種程度是支持 Open Source 的公司。就我所知,Yahoo 是間很早開始支援 Hadoop 開源專案的公司。Yahoo 使用 Hadoop,也延攬 Hadoop 開發者進公司,所以「不擁抱其他 Open Source 團隊維護的專案」這個論點也許是存在的。

我們來看看 Google。類似於 YUI,Google 自己也有一套 Closure Library,多數 Google 的產品都建構於其上,雖然開源,但外面專案會使用它的也少之又少。 而 Android 呢,AOSP專案裡也有不少只能在 Android 工具鏈中使用的工具,但從以前基於 Eclipse 的 Android 開發工具到最近釋出的 Android Studio 1.0 是基於 IntelliJ 的開發工具,部分的 Google 似乎較接受擁抱其他 Open Source 團隊維護的專案。

在寫下這兩段話的同時,我比較這兩家公司擁抱其他 Open Source 團隊維護的專案的原因,竟發現兩者改變的相同點在於「併購」。當 Google 併購 Android,就接受了 Android 團隊與他們提出的開發工具。當 Yahoo 開始大採購,許多新創團隊進入 Yahoo 大家庭的同時,也帶進各團隊使用的「其他 Open Source 團隊維護的專案」。也就是說,當新移民團隊進入這個團體時,帶來了改變。

比起大公司而言,新移民團隊在被併購前的資源有限,使用其他 Open Source 團隊維護的專案是很自然的事。團隊被併購後若需使用併購方的技術重新打造產品,將是相當痛苦的事情。因此在 Yahoo 大採購後許多原有規矩被改寫,恐怕背後也有這些新團隊帶來的影響。

用社會學可能可以解釋為什麼是團隊而不是個人?因為改變一直是困難的事。原有的團隊在過去磨合 / 開發的過程中已經凝聚出了一些共識。移民到新團體的過程中,新移民團隊需要參與和適應團體的一些運作方式,而團體則需接納和適應新移民團隊的一些習俗。

回來想想 Mozilla 也做了很多 Open Source 專案,但整套工具常常僅供自己相關的專案使用。 從自身找原因,自家工具的開源專案原本就是為了滿足自己的需求。當外部出現對這套工具的需求時,由於公司人力資源調配,優先要滿足的還是自身專案時程的需求。 當用到的 Open Source 專案在公司裡就有人可以諮詢,當然比去找其他 Open Source 團隊維護的專案來地可靠(?)。許多專案在這樣的思維下就使用自己寫的工具,當意識到的那天,已經回不去了。

若想避免現在的 feature 變成未來的 bug,在決定自幹專案工具前,先想一想(或 search 一下),也許結果會不一樣。

· 2 min read

FoxBox is the project that intent to provide a battery included Firefox OS build environment.

The goal of foxbox is to try any approach that make new user can do as less as possible to start the FirefoxOS development

Our first take is use vagrant with virtualbox to make major platform users can try FirefoxOS dev in VM.

It will be great to setup the current version of foxbox in your desktop environment

And record obstacles you encountered here There are some issues (but not the limit) that might be worth to do in the future version of foxbox.

Note that you require a desktop with INTEL VT-x/AMD-V hardware virtualization support(Windows8 or Mac already enabled it), at least 4GB RAM and about 10~40GB disk space(for gaia or full B2G development).

FoxBox has been approved by the Google Summer of Code administrator , so its perfect time to step up, try FoxBox, fix issues that every others will encounter, save everybody's time and start make your own Firefox OS phone.

If you'd like to contribute FoxBox for SummerOfCode14. We expect you could find out the interesting topic you want to contribute or any other way that can better achieve FoxBox's goal.  

· 5 min read

第一個中文世界的開放徽章 「徽章」讓原本難以量化的能力,透過徽章的形式具現化。


最常見的遊戲化(Gamification)應用是 PBS(Point, Badge, Scoreboard)- 積分、徽章、排行榜。這些遊戲化元素在許多遊戲和社交網站中都會出現,如 KhanAcademyCodeAcademy 等近年湧現的線上學習網站。在站內學習時,每完成一道題目,就可以取得一定的分數;完成了一個學習單元?恭喜!你獲得了一個線上的徽章,可以把聯結展示給你的朋友或潛在僱主看。

但目前的遊戲化(Gamification)應用有個問題:我已在這平台 / 遊戲上投入了那麼多時間、精力,(可能還有金錢),一旦不用這平台 / 遊戲之後,那些我的豐功偉業都不見了。於是使用者 / 玩家會傾向停留在剛開始選擇的平台中,並減少嘗試其他家服務的意願。於是「Lock in」、大者恆大的現象就出現了。

也因此 Apple、Google 都仿效 XBox 推出自己的 Game Center,提供積分、徽章(成就)、玩家配對等功能,讓在同一個平台上的玩家更方便嘗試不同遊戲,並且保留遊戲的進度,期望能綁住使用者 / 玩家。

這個現象對遊戲或作業系統平台商而言也許是好事,但是如果把目標改成線上學習網站的話... 我是希望可以在更專門的網站學習不同的技能啦。 而且最好是不管線上或學習實際課程後,我都可以得到徽章 / 證書,這樣我可以把我收集到的成就展示給我的朋友或潛在僱主看。


Mozilla 嘗試在推動的 OpenBadges(開放徽章)標準就是一個解決線上 / 線下,不同網站之間徽章 / 成就流通,鼓勵使用者多多嘗試的方案。

前幾週在我講授的 COSCUP 課程 上,發出了第一個(? 我想應該是吧)中文世界的開放徽章


1. 學員聽完第一個小時課程,並已實際 Lab 操作一陣子,符合取得徽章的資格 2. 提供學員印出的徽章兌換券,上面的內容如下

徽章兌換券 3. 學員直接使用智慧型手機掃描條碼,或前往 網站輸入兌換碼。 4. 學員登入後可取得徽章

5. 取得的徽章可以直接分享給他的朋友或潛在僱主看,或導出到 徽章背包 ( 中備份。所有符合 OpenBadges 標準的徽章都可以備份到 徽章背包 中。學員可以結合其他網站上取得徽章,將這些徽章整理成一個個收藏(Collection),有系統地分享給他的朋友或潛在僱主看。


除了讓使用者願意多方嘗試之外,同時也讓一般人擁有發放徽章 / 證書的能力。從初步的使用經驗來看,開放徽章還有很多的可能性值得探索。

· One min read

上週在 Coscup 2013 演講的投影片,介紹為何要參與 Open Source 專案,基本 Firefox OS 架構,和 web 技術人如何運用自己的能力來參與 Gaia 專案開發。

Steps to contribute to firefox os (gaia) 

為這次演講花一個晚上做了一個簡單的 hack demo,在撥打電話時,馬總統會報出正在播的數字。


聲音來自 Open Source 的 Bumbler to speech 專案。