Armen Zambrano's battlefield

Running Windows 8 tests visibly on tbpl

noreply@blogger.com (Armen Zambrano G.) — Tue, 19 Mar 2013 18:17:00 +0000

A couple of weeks ago we announced that we were running Windows 8 test jobs on the Cedar tree but we're now also running it on mozilla-central, mozilla-inbound and try.

We have 3 types of jobs hidden for these reasons:

Reftests will soon land on mozilla-inbound and be fixed
Debug mochitest-2 and debug mochitest-other are intermittently failing (more often than Windows XP and Windows 7)

If you want to lend a hand with these last issues please visit bug 847447 and see how you can help.

We will soon enable it on every other branch besides mozilla-esr17 in bug 847471.

It's good to see these running officially :)

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Running Firefox unit tests on Windows 8

noreply@blogger.com (Armen Zambrano G.) — Tue, 05 Mar 2013 22:25:00 +0000

Last week, we started running Windows 8 unit tests in the Cedar development tree:
https://tbpl.mozilla.org/?tree=Cedar&jobname=Rev3 WINNT 6.2

Unfortunately a bunch of jobs are not passing all tests :( We have filed "Bug 847447 - Figure out list of failing win8 jobs and chase them down" to figure how to solve those unit test failures.
If you can give jimm and others a hand with those bugs that would be greatly appreciated!

Once we add the remaining Windows 8 machines to the pool of machines, we we will enable the test jobs on every other development tree and hide them until green. This way, we can have a better idea of the load to expect.

To track the project as a whole, visit: "[Tracking bug] test 32bit windows build (which include metro functionality) on 64bit version of win8".

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Handing off Armenian localization to others

noreply@blogger.com (Armen Zambrano G.) — Sat, 12 Jan 2013 22:29:00 +0000

For a very long time I have been involved with the Armenian localization process for Mozilla but since I got married I had to re-prioritize where I would put my time into.

In this post, I will describe what pieces of knowledge I gathered over the years and try to write something that others can use. Please forgive the lack of structure and whatever mistakes I make.

NOTE: "L10n" is shorthand for Localization; which is the process of translating texts plus everything else involved to get the products adjusted for a region and releasing to users.

To learn more you can read the official documentation in here:
https://developer.mozilla.org/en-US/docs/Localization_Quick_Start_Guide

To ask questions you can visit the Google Group for L10n:
https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.l10n

Concepts involved

Mozilla's development cycle

every 6 weeks there are new strings to be translated
The strings travel through 4 different versions of Firefox

Nightly -> Aurora -> Beta -> Release

We do translations in the Aurora cycle which it's supposed to be the first cycle frozen with regards to new texts to be translated

Product translations

How to translate Firefox, Thunderbird and Firefox for Android

Every 6 weeks (matching the opening of an Aurora cycle), I would remind contributors with an email or a Facebook post with instructions on what to translate

Web translations

Web pages translated into Armenian

Bugzilla

Issue tracking system

Mozilla.am and Facebook
Accounts

1 - Mozilla's development cycle

Here's a brief explanation on how developers change Firefox and include texts to be translated. Developer's create code changes and add texts to be translated while Firefox is on the first six weeks' development cycle. This period is called Trunk, Nightly (since every night a new update is generated) or the latest version of the product or mozilla-central (central point of integration).

After six weeks of changes the code is taken from Trunk/Nightly to Mozilla Aurora. In this cycle translations are not to be changed. It is at this point in time that we want to translate texts since there should be no new texts to be added on this six weeks cycle. The code and translations on Aurora are generated every morning for every language and for every platform. If your team introduces new translations it will be integrated on the next morning's update. On this 6 week period, you are expected to do your translations, submit them and then sign them off (more details later).

After this Aurora period passes, the translations move into the Beta cycle where a much larger audience tests all products. At this point, missed translations can still be taken if necessary. Approximately one beta is generated every week.

After this Beta development cycle, the beta product reaches the Release cycle where millions of users get to use it. The majority of users don't know any other cycles besides the Release one and they are not aware that there is such a concept as the release version. No translations are to happen on this period either. One version is produced at the beginning of the cycle and security releases only occur due to major security issues.

Here's a summary:

Nightly: First 6 weeks, new texts appear on Nightly
Aurora: Second 6 weeks, all texts are ready to be translated
Beta: Third 6 weeks period, you should have translated all your texts on the Aurora period. The translations from the Aurora period are kept on this cycle.
Release: The last 6 weeks are exactly the same as the Beta period. No translations. They are kept exactly the same

2- Product translations

There are several ways of translating the various Mozilla products [1]. One of them is Narro, which a web tool. My recommendation is to abandon such project and continue with Pootle's version. The guys running it are very responsive and are much more involved with the translations they support. We have had way too many issues with Narro in the last 2 years. I'm not sure if they have support for all three products or not. Visit the Armenian page they set up for us: http://mozilla.locamotion.org/hy_AM.

Nevertheless, here are the instructions on how I used to do it with Narro.
A complete set of tutorials are documented in here:
https://developer.mozilla.org/en-US/docs/Localizing_with_Narro

[1] https://developer.mozilla.org/en-US/docs/Localization_Quick_Start_Guide/Translation_phase#Mozilla_applications

2.1 - Translate with Narro

Every 6 weeks you want to encourage your team of contributors to translate the new set of texts available. Narro should automatically import into its database the translations from Mozilla's Mercurial:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/hy-AM

Roberto Reyes from the Tagalog team has created a simple video showing how to translate in Narro:
http://www.youtube.com/watch?v=EtoLPL_JIG8

I also wrote a more in-depth blog post about the topic:
http://armenzg.blogspot.ca/2010/10/how-we-use-narro-to-localize-firefox.html

2.1.1 - Review other people's translations

Some users in Narro can actually review and approve other contributor's suggestions. Only reviewed translations should make it into the Narro exports.

2.2 - Export Narro into Mercurial

The translations of your team won't be official until they are committed/submitted to Mozilla's Mercurial servers. Mercurial is a version control system that can store the translated files. Narro exports the translations in a zip file that has the same structure as the files in Mercurial.
Every 6 weeks (or every time you get a bunch of translations) you should export and commit your translations into Mercurial. Don't leave it until the end of the 6 weeks cycle of Narro could fail you. The next day your translations will be included on the Armenian Aurora version of Firefox for desktop and mobile plus Thunderbird:
http://www.mozilla.org/en-US/firefox/all-aurora.html#hy-AM (Aurora is the second cycle out of the four development cycles)

On the first week of every new release cycle export the changes from Narro and import them into Mercurial's Aurora repository (http://hg.mozilla.org/releases/l10n/mozilla-aurora/hy-AM)
To know the beginning of each 6 week period visit this page:https://wiki.mozilla.org/Releases#Upcoming_Releases

Steps (rough outline):

Load each Narro project: Firefox Aurora, Fennec Aurora & Thunderbird Aurora
Load the “Export” tab for each one and download the zip file for each
Download the zip file and unzip unto your Mercurial checkout
Make sure that you run “hg st” to know if you have any files not going in
Watch the video and read this post for more details: https://blog.mozilla.org/l10n/2012/07/16/tips-tricks-cleaning-up-narro-exports

On this video I show how I export the translations and I clean up the code before submitting (committing) them to the Mercurial servers:

You can see a post explaining how to clean up your export:
https://blog.mozilla.org/l10n/2012/07/16/tips-tricks-cleaning-up-narro-exports/

Narro trick

The following post explains how to prevent Narro from exporting specific files. This is useful for some files that require review from the L10n driving team.
http://armenzg.blogspot.ca/2011/12/how-to-exclude-file-from-being-exported.html

2.3 - Sign off on the L10n Dashboard
To communicate to the L10n team that your translations are ready for a development cycle you have to sign off. To sign off is to use a webtool to mark a specific submission to Mercurial as ready to be released.
After we import the changes into Mercurial in 15-20 minutes we should see the results on this dashboard:
https://l10n.mozilla.org/teams/hy-AM

We only care about “fx_aurora” (Firefox), “fennec_aurora” (Firefox Mobile) and “tb_aurora” (Thunderbird) when we want to take care of current needed translations
Once your commits have greened out you have to click on the icon that looks like a magnifying glass (This is to mark a sign off)
Only people who are signed in and have the right privileges can submit a sign-off.

2.4 - Example of status communication

Every 6 weeks blog/email the group of potential localizers so they can do the translations:

Hi,

In 6 weeks version 20 of the various Mozilla products we translate into Armenian will be released to the beta audience.

We're not doing great for the Firefox Desktop version. If you could think of who could help us do translations please let us know.

For translations click on the following:

Desktop - 150+ texts to be translated
Android - 144 texts to be translated
Thunderbird - 212 texts to be translated

For reviews (some of you can actually do reviews):

Desktop - 150 texts to be reviewed
Android - 11 texts to be reviewed
Thunderbird - 2 texts to be reviewed

You can tests these translated versions in here:

Desktop (Windows, Mac & Linux)
Android - Look for the apk that says "hy-AM"

Best regards,
Armen

3 - Web translations

If you look at the L10n dashboard:
https://l10n.mozilla.org/teams/hy-AM#webdashboard
You will notice that there is a web dashboard that leads you to all web translations still needed:
https://l10n.mozilla-community.org/webdashboard/?locale=hy-AM

If you follow the link of missing strings it will take you here:
http://l10n.mozilla-community.org/~pascalc/langchecker/?locale=hy-AM#main.lang

On the side you will see instructions on how to attach translations:

Identical	Translated	Missing
6	102	0
Original English source file
Your translated file
Attach your updated file to Bugzilla

4 - Bugzilla

In the software industry, issues are tracked with issue tracking systems which are also known as bugs. Mozilla has a database called Bugzilla which tracks issues of all sorts. In the case of L10n, there are bugs that are specific to your language (a.k.a. locale).

On the dashboard you can find a summary of the bugs for your locale:
https://l10n.mozilla.org/teams/hy-AM#bugzilla

Each bug have different instructions on what to do.

5 - Mozilla.am and Facebook

Mozilla.am is the Armenian site that promotes Mozilla and I believe it is still maintained by Robert Sargsyan
http://www.mozilla.am

I have also found that Facebook is a good way to engage people (better than email). I have in the past pasted an etherpad with web translations and asked for help:
https://www.facebook.com/groups/firefox.in.armenian
https://etherpad.mozilla.org

6 - Accounts

What sort of accounts could a locale's administrator need?

A project admin account on Narro.

You can request one in the Narro newsgroup.

SVN access

A bug needs to be filed.
pascalc can also land things by asking him on bugs
A SVN account expires after 6 months of not being used

Mercurial access

A bug needs to be filed.
The people from Narro and Pootle can help you land your code

Sign-off privileges

A bug needs to be filed (I assume so. I don't know under which component)
Ask on the L10n newsgroup or directly talk with Pike

I hope this blog post is somehow useful for the continuation of the Armenian localization.

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Running Gaia UI b2g panda tests on the Cedar branch

noreply@blogger.com (Armen Zambrano G.) — Thu, 10 Jan 2013 17:28:00 +0000

Back in November, Release Engineering tackled with IT, the A-team and the B2G team, the undertaking of running in production the Gaia UI tests on the b2g pandas [1].

Back in December 7th, we managed to get all the piping done for re-imaging pandas and assigning dummy jobs to them (see "B2G test jobs running on panda boards on the Cedar branch" post for details).

Last week, after I came back from holidays, I was pleased to see that one of the last blocking bugs had been solved (bug 820617 - Add a hook to make NetworkManager not manage offline status and use it in Marionette for B2G CI) and I could now try to run the tests.

Last Friday, we landed the code to actually run the tests [2]. This is simply run with a mozharness script like this:

/tools/buildbot/bin/python scripts/scripts/b2g_panda.py --cfg b2g/panda_releng.py

At that point in time we stopped running dummy jobs and started running tests for the first time.

Since then, then test jobs have been failing but we are working on the last few bugs to get them to be green. See bug bug 829053 (Gaia UI tests failing with JavascriptException: TypeError: settings is null) if you're curious.

Thirty five fixed dependent bugs later (and 2 bugs left to be fixed) I can say that it has been a great joint project and I have personally learned a lot through it.

It would have great to have completed it a while ago but too many difficulties and code problems were found.

I hope to write to you soon once the tests go green and we start running them every b2g branch.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=802317
[2] http://hg.mozilla.org/build/mozharness/rev/caf3b92e7207

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

B2G test jobs running on panda boards on the Cedar branch

noreply@blogger.com (Armen Zambrano G.) — Fri, 07 Dec 2012 20:34:00 +0000

(This was posted on Dec. 7th but it seems I forgot - thanks edmorley for noticing - to add the "planet" tag so it would show up on planet.mozilla.org)

Hi,
I want to announce that we recently started running test jobs on the Panda ES boards. These are running on tbpl on the Cedar branch:
https://tbpl.mozilla.org/?tree=Cedar&jobname=b2g_panda&noignore=1

These jobs are currently not running real tests but testing the plumbing. It tests that we can image the boards and that they come back up.

This is how the process work:

We detect that a new b2g panda image has been uploaded to a private location
We give the job to a buildbot instance on one of our servers
The buildbot instance, through API calls, requests the specific device associated to it from Mozpool [2]
Mozpool downloads the b2g artifacts and re-images the device
Buildbot waits for a fixed amount of time for the device to be "ready"

In later models it will be able to request "any" device rather than a specific model

Once the device is available we run a small test which is to cat /system/b2g/application.ini

This shows from which build it got re-imaged and that we can run something on the board

Once we run that test we return the device to Mozpool and finish the job

Here's the log of our first working job in production:
https://tbpl.mozilla.org/php/getParsedLog.php?id=17716049&tree=Cedar&full=1

Our first candidate for tests running on the pandas are the Gaia UI tests [3]. Right now, those tests can not be run remotely but the work of getting it working is getting closer to be completed.

While that happens, on the releng side we will be fixing issues we're finding on the Buildbot <-> Mozpool <-> Panda interactions. Not all green jobs are yet real successful jobs. We should recover better from the failing imaging jobs.

This is a very neat and improved imaging system by introducing Mozpool to our systems (Which is a mix of BlackMobileMagic - aka bmm -, LifeGuard and Mozpool). The A-team and IT developed this great system.

Due credit to aki, ahill, Callek, catlee, ctalbert, digi, dustin, dividehex, nthomas, jgriffin and jhopkins for getting us this far.

More to come; stay tuned!

[1] http://pandaboard.org/node/300/#PandaES
[2] https://wiki.mozilla.org/ReleaseEngineering/Mozpool
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=802317

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Juvenile diabetes? You can help!

noreply@blogger.com (Armen Zambrano G.) — Tue, 25 Sep 2012 19:00:00 +0000

Hi,
Every day many of our friends and relatives face diabetes.
My friend Greg has been cycling to Niagara Falls for the last 6 years raising awareness and donations for diabetes research.
Please consider donating to this cause. Every little counts:
http://jdrfca.donordrive.com/index.cfm?fuseaction=donorDrive.participant&participantID=164692

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Nightly updates for Firefox for Android on Armv6 (development purposes)

noreply@blogger.com (Armen Zambrano G.) — Fri, 06 Jul 2012 19:20:00 +0000

Today we enabled updates for Firefox for Android on Armv6 and symbols.
I had previously announce that we enabled these builds for when developers committed changes for Firefox. Today we're announcing that you would also get updates every day.

NOTE: Be warned that these builds have not got full attention from developers as the armv7 builds do. I don't even know what is the right place to file bugs/issues for it.

You can download it and test it in here:
http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/latest-mozilla-central-android-armv6/fennec-16.0a1.en-US.android-arm-armv6.apk

The work got accomplished in:
https://bugzilla.mozilla.org/show_bug.cgi?id=723946

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Initial automated Armv6 builds for Firefox on Android (for development purposes)

noreply@blogger.com (Armen Zambrano G.) — Thu, 21 Jun 2012 19:55:00 +0000

Today we enabled Armv6 builds for Firefox on Android.
This will allow contributors to know that their changes do not break the compilation of this specific target.

You can see these jobs running on tbpl (Mozilla's continuous integration reporting tool):
https://tbpl.mozilla.org/?jobname=armv6

For now, we don't suggest you to install these Armv6 builds until we can verify next week that the update system is working as expected.

If you are interested on knowing when this will happen you can subscribe where the work is happening (the bug is used for getting things working rather than discussion of release dates):
https://bugzilla.mozilla.org/show_bug.cgi?id=723946

Best regards,
ArmenZG
------------
Release Engineering Team

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

How to export and sign-off translations from Narro for Mozilla Firefox

noreply@blogger.com (Armen Zambrano G.) — Thu, 31 May 2012 20:15:00 +0000

Hi,
For few years I have been trying to help the Mozilla Armenian localization initiative (even though I can't read/write Armenian myself). A friend of mine asked me if I could do a screen cast showing how I export the translations that the localizers translate.

Excuse my lengthiness and, perhaps, not clarity that a well thought video could have avoided. Release early it is said.

Here is a 15 minute screen cast explaining this:

Here is the script that I run during the video:

modules=( browser dom netwerk security toolkit); \
for module in ${modules[@]}; do cd $module; \
for file in `find . -name "*dtd" -type f`; do \
cat /Users/armenzg/repos/armenian/header.dtd $file > $file.new; mv $file.new $file; done; \
for file in `find . -name "*properties" ! -name region.properties -type f`; do \
cat /Users/armenzg/repos/armenian/header.properties $file > $file.new; mv $file.new $file; done; \
cd ..; done;

FIND="browser dom netwerk toolkit services security"

for file in `find $FIND -name "*dtd"` ; do \
sed '${/^$/d;}' $file > $file.new && mv $file.new $file ; done
for file in `find $FIND -name "*properties"`; do \
sed '${/^$/d;}' $file > $file.new && mv $file.new $file ; done
for file in `find $FIND -name "*ini"`; do \
sed '${/^$/d;}' $file > $file.new && mv $file.new $file ; done

hg revert dom/chrome/layout/xmlparser.properties \
dom/chrome/layout/htmlparser.properties
for file in `hg st -un | grep searchplugins`; do rm $file; done
for file in `find . -name "*orig"`; do rm $file; done

cd ../compare-locales && git pull && cd - && \
cd ~/repos/branches/mozilla-aurora && hg pull -u && hg up -C; \
cd ~/repos/armenian/hy-AM_aurora

PYTHONPATH=../compare-locales/lib python \
../compare-locales/scripts/compare-locales \
~/repos/branches/mozilla-aurora/browser/locales/l10n.ini \
../hy-AM_aurora .

Here is a list of the three posts I have made about Narro:
http://armenzg.blogspot.ca/search/label/narro

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Help to translate Firefox/Thunderbird into Armenian

noreply@blogger.com (Armen Zambrano G.) — Fri, 27 Apr 2012 15:56:00 +0000

Hi!
This week we have a new set of texts to translate into Armenian.

If you could focus on the Android version that would be great!

For translations click on the following:

Thunderbird - 46 texts to be translated
Firefox for Android - 150 texts to be translated
Firefox for Desktop - 752 texts to be translated

You can try these upcoming Aurora versions by downloading them from here:

You can visit our Facebook group to get help with it:

Firefox in Armenian

Thanks for your help!

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Welcome to Jordan Lund - Our new release engineering intern

noreply@blogger.com (Armen Zambrano G.) — Mon, 02 Apr 2012 15:55:00 +0000

Flying all the way from Ireland, I am thrilled to introduce to you to Jordan Lund our new release engineering intern.

Jordan is from Vancouver, B.C. but studying in Dublin Institute of Technology.
He will be working on moving our buildbot infrastructure to use mozharness which aki has blogged several times about. This work will make contributions to our systems much easier among many other internal advantages.

His first project will be to match our desktop localization (buildbot based) repackages to our mobile localization (mozharness based) repackages.

Jordan will be based off from Toronto for the next six months. He will be hanging out in #build on IRC and his nickname is jlund.
I encourage you to ask him about what volunteering he has done back in British Columbia :)

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Need help translating into Armenian

noreply@blogger.com (Armen Zambrano G.) — Sat, 03 Mar 2012 17:33:00 +0000

Hi,
We need the following strings translated into Armenian for Firefox websites. Would you be able to give us a hand?

Please follow the same format and only translate the line that does not start with semi-colon ";":
https://etherpad.mozilla.org/1ShelKh8lc

Thanks,
Mozilla's Armenian Localization Team (Facebook group)

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

talos.zip, talos.json and you

noreply@blogger.com (Armen Zambrano G.) — Thu, 22 Dec 2011 19:54:00 +0000

I have deployed today a small change that modifies how we deploy talos.zip to the performance/talos jobs.

In short what the change does is this:

Download talos_from_source_code.py
Which downloads http://hg.mozilla.org/mozilla-central/raw-file/default/testing/talos/talos.json
Which contains where to download the talos.zip from (http://build.mozilla.org/talos/zips/talos.zip - accessible to build machines)

That's it. Nothing else. Nothing more.

How does this help?

Every new talos.zip we place under build.m.o will require a commit on the tree
Only when the change lands on the repo that talos.zip will be used
A newer talos.zip will only be used from that changeset onwards
Any regressions caused by the new talos.zip will be blamed to a changeset on the tree
Such changeset can be backed out by anyone without the need of releng

What are other side-effects?

We can run a talos.zip through the try server and use compare-talos
We don't need a downtime anymore to land a talos.zip
The new talos.zip cannot affect any other branches
We can run an old changeset with the talos.zip that was used for it
We can extend the talos.json file to control other moving parts like plugins

If we could summarize it in one sentence it would be:
"One changeset, one talos.zip"

This different model is not new as Jetpack already had it (jetpack-location.txt).
This model locks every changeset on a tree to a specific state of an external force.
In other words, we can configure parameters from inside tree.

Best regards,
Armen

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=673131

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

How to exclude a file from being exported in Narro

noreply@blogger.com (Armen Zambrano G.) — Tue, 20 Dec 2011 18:28:00 +0000

Browse to the file
Uncheck "Export with project"

How to exclude a file from being exported in Narro

This is useful when there are files that require explicit approval from L10n release drivers.
We recently changed our search engines for Armenian and a Narro export reverted the changes. This caused Axel to file a regression bug for me to fix it.

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Changing how talos.zip gets deployed

noreply@blogger.com (Armen Zambrano G.) — Tue, 22 Nov 2011 20:18:00 +0000

For the longest time I have been looking to have time to work on this project to make everyone's life easier.
Bug 673131 - when minor talos changes land, the a-team should be able to deploy with minimal releng time required

What about if we could limit talos changes as any other change that lands on the tree?

Currently what we do is to download a talos.zip that replaces the old one in one of our build machines. This means that as soon as any job starts a talos job it will grab the newest talos.zip.
To read about some of the problems that this causes you can go at the bottom of this post.

I will tell you what I want to change even though I don't yet know exactly how to do it.

INITIAL DESIGN

the talos job downloads a text file:

e.g. hg.mozilla.org/mozilla-central/raw-file/abcd1234567/path/to/talos/config/file.json

that file will contain the URL of the talos bundle

e.g. people.mozilla.com/~armenzg/talos/talos.zip

the talos bundle will be downloaded

INITIAL CONCERNS

how to prevent a talos.zip to contain malicious code and cause us harm?

anyone with try commit level could tinker with a machine inside of the build network (even though we don't ship anything from such machine)
we should find a way to limit this
perhaps have this feature only available to a give project branch? A-team branch?

we could add a cgi script to upload a talos.zip
maybe we should redesign this to just indicate a "revision" and update to it for http://hg.mozilla.org/build/talos

it forces to match a build to a given talos.zip

this means that if you want to try another talos.zip you will have to push a different changeset to specify a different talos.zip to be used even though the build is exactly the same

I am also afraid that this project could easily start scope creeping knowing how many artifacts we download for talos (e.g. pageloader.xpi, plugins et all).

CURRENT SETUP PROBLEMS
I wanted to have this section in case there was somebody curious about the problems we face with the current setup:

no need for downtimes as changes are isolated to a changeset landing
a changeset can have some talos jobs test the old talos.zip and the new one

this can make some platforms to show a new regression on that changeset and some on the next one. This makes it hard to figure things out

a build that started before the talos.zip was deployed can be blamed for causing a regression even though the talos.zip was deployed *after* the talos.zip was deployed
a talos.zip change does not show up on the pushlog

this means that it can only be noticed if a note is sent to dev.tree-management or if the Maintenance page was updated correctly
this means that it can not be backed out by a developer

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

My first mobile testing hours

noreply@blogger.com (Armen Zambrano G.) — Fri, 18 Nov 2011 22:55:00 +0000

I decided to spend few hours learning the process of submitting Fennec issues and documenting it. I would like to be doing this 30-45 minutes every day to help the project.

I documented my learning process in:
https://wiki.mozilla.org/User:Armenzg/Fennec_Native_UI_testing

For the record, I had to remove the multi fennec build from latest-birch as it was broken.

At the end of this post there are some easy to hit bugs which would save you the time to figure out if it is already filed.

I hope this can help you get started and see that is not hard to do it.

First steps

Read https://wiki.mozilla.org/Mobile/Testdrivers_Program
Sign-up at to the mobiletestdrivers mailing list
Instal build fennec-11.0a1.en-US.android-arm.apk

NOTE: Here's the list of bugs that I've filed or have CCed myself to.

Testing

If you hit a bug check the list of know bugs Fennec Native UI list.
- I normally just use the integrated search (Ctrl + F) that comes with Firefox to search through the list
- I keep open the list all the time
If you don't find it file it by typing the steps you followed plus your expected behavious.

Not tried yet:

blassey told me to use "adb am start " to tell from my laptop to my phone to open a URL
Note on taking screen shots:

You can take screenshots using the Android SDK; you don't have to root
the device.  The other way is to upgrade to ICS if that is an available option
for you.

The android sdk will install the ddms, in which you can select a device and
then take a screenshot

Issues found

These are issues that I have not yet filed or have not have had time to check if they are valid.

On first start up I go to the Firefox Nightly start page and it is crazy wide
"Reformat text on zoom" is not "on" by default

Easy to hit bugs

Last updated: Nov. 18th, 2011

bug 702633 - painting is broken for google.ca
bug 701380 - have a different start up page
bug 701594 - Should not be able to stay zoomed out further than the page width
bug 700940 - Favicon transparency results in purple background sometimes
bug 701797 - "save as PDF" is broken

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

How FSOSS was for me

noreply@blogger.com (Armen Zambrano G.) — Tue, 01 Nov 2011 15:43:00 +0000

Last week at FSOSS a lot of good things happened for me and writing about it in an organized manner will be a bit challenging :)

As I mentioned last week, I gave a new talk at FSOSS on Saturday morning. I spoke about what is involved on shipping open-source software to millions of users (I will add the presentation in another blog post). I had the opportunity to bring my sweet beloved Veronica with me and according to her "[my] presentation was wonderful! best looking guy there ... and [my] talk wasn't too bad either!... I learned so much (though your handsome face was quite distracting! :) )". A little biased but I got to say that it felt like it came about right and I had a lot of fun.

During Q&A for my presentation.

I had started working on this presentation on Tuesday and had the opportunity to run it through Mike Hoye who had encouraged me to give the talk a month ago. His input was valuable and helped me with some problems I was having.

Besides my presentation there were many things that happened on Thursday, Friday and Saturday.

As soon as I got my bag of swags I realized that most sponsors (and not sponsors) were represented in it (see pic below). I was surprised that I did not see anything from us even though Mozilla was the biggest sponsor of the event.

Mike Hoye giving his presentation.

No Mozilla swag on the welcome bag.

Me, Jeff Griffiths and two Microsoft evangelists

I spent most of my day with Jeff Griffiths at the Mozilla booth. Over there, I realized what big of a brand Mozilla is and the affinity that Seneca students have with us. I was overwhelmed with how many came to us to find out how to contribute or how to take part of an internship.

I also noticed a couple of things while I was at the booth. I noticed there were a couple of non-open-source booths like Microsoft. I guess events like this need sponsors to give money regardless of how much open-source they do. Regardless of this, I went and spent some time with them as I was curious on the Microsoft phone (which felt much better than I had expected). I was really impressed that they had three people and all sorts of cool swags and phones all over. They also had a very cool shirt that says "I love Windows phone" with icon-apps rather than words (see pic). I also like their slogan "Make web not war" which is catchy.

I wish this event was more widely known and have more people coming to it as there are some good talks. Seneca staff and students did an excellent job at running this event. It felt like they do this every day.

I also had an opportunity to meet again many of my former professors and Shaz (I used to work for her as a student ambassador at student services). Tim McKeena (Seneca prof.) was extremely excited to hear my talk and gave me a small gift from Seneca.

I wish I attended more sessions but working on the booth and preparing for the presentation took most of my time.

Keep it up Seneca!

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Mozilla's release process at FSOSS

noreply@blogger.com (Armen Zambrano G.) — Mon, 24 Oct 2011 19:55:00 +0000

FSOSS is back and this year I will be there presenting a new presentation. This time I will be talking about the release process at Mozilla.

Last year I presented about Mozilla's Release Engineering infrastructure which is accomplished with many open-source tools but mainly by Buildbot.

I am looking forward to see you there!

On another note, you will have in total four Mozilla co-workers presenting about different topics:
How to ship Open Source software to half a billion users - Armen Zambrano Gasparnian
http://fsoss.senecac.on.ca/2011/node/108

How Web Browsers Work - Ehsan Akhgari
http://fsoss.senecac.on.ca/2011/node/113

Introduction to Mozilla's Add-on SDK - Jeff Griffiths
http://fsoss.senecac.on.ca/2011/node/77

Take control of your TV with XBMC - Lawrence Mandel
http://fsoss.senecac.on.ca/2011/node/58

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

How I got involved with Mozilla's Armenian localization and we shipped it :)

noreply@blogger.com (Armen Zambrano G.) — Mon, 26 Sep 2011 18:00:00 +0000

I have been asked how I got involved with the localization process and I would like to have a post so I can always make reference back to it.

It was back at the beginning of 2007 when Dave Humphrey taught during Seneca's study week how to Dive into Mozilla. After that, he encouraged us to take on a project and push it forward. Most of the projects sounded scary, I lacked technical confidence and were not important to me. The only project that caught my attention was to translate Firefox into Armenian. My grandfather had recently started using the Internet and I was hoping to make him happy by making the browser to be in Armenian (his mom's tongue). My major problem was that I did not read/write Armenian so I had to teach myself. The other problem I had was that the localization process was convoluted with wiki pages and lacking a Mozilla supported web tool. I left the project for a while as I undertook the development of a localization tool.

It was during the summer of 2008 that Robert Sargsyan contacted me and soon after we managed to get him an approver's account on Narro (a web tool for localization).

During 2009 there was a long silence but Robert kept on working hard for all those months. In September, we setup a Mercurial repository on bitbucket and figured out all issues and imported the translations from Narro.

Early in 2010 we opened a registration for the Armenian team and created a language package for Firefox 3.6 while we waited to receive the approval. On August 2010 the first import landed and on November we managed to make it for Firefox 4's beta 7.

Since then you can download Firefox in Armenian in here.

My grandpa never got to use Firefox in Armenian as he passed away before that but I bet many other grandpas will be able to.

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Mozilla's Automation Infrastructure explained (DRAFT)

noreply@blogger.com (Armen Zambrano G.) — Fri, 09 Sep 2011 22:20:00 +0000

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Win64 status update

noreply@blogger.com (Armen Zambrano G.) — Fri, 09 Sep 2011 16:03:00 +0000

Hi all,
Since my last status update a lot of things have happened:

The opt builds are going green
The builds are now showing on the developer's dashboard: tbpl.
All branches have win64 builds (I have added the last few this morning)

We have try support for win64 (implied in previous point)
We don't have win64 support for aurora, beta, release and 1.9.2

What is it missing to be at par with other operating systems?

Testing infrastructure

We currently have 5 Win7 64-bit machines and they are only testing mozilla-central (as of today) to keep up
The other 50 that we had were repurposed 3 months ago for the other operating systems so we could increase their capacity by 8-10%. It was a tough call but it was necessary to keep up.

Debug builds

Symbols. It seems we are hitting a Microsoft bug. We will disable them for now
Packaging.

Symbols for the try server.

Perhaps some people won't agree that we should make the tests visible for mozilla-central since we don't have testing coverage for other branches. Nevertheless I believe that it makes sense that we could have a way of seeing tests failing rather than not at all. If it takes us 3-4 weeks to clone more machines we would be adding test failures without seeing them. I don't think it is asking for too much to try to file a bug for a test failure and carry on (even hide it) if we are not willing to back the change out or to fix the failure. At least we would have a merge to blame for or a range of pushes to help debugging the issues. If you disagree feel free to do what you think is best for everybody.

EDIT: Fixed typo 64-bi instead of 65-bit.
EDIT: For further info please follow the tracking bug.
EDIT: To try the build go to http://nightly.mozilla.org

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Win64 builds status update

noreply@blogger.com (Armen Zambrano G.) — Mon, 22 Aug 2011 16:49:00 +0000

Two things:

we now have all Win64 build machines cloned
we now have all branches with Win64 builds (Try coming soon)

The builds are currently not compiling but khuey and Makoto Kato are tackling each issue until we get back to compiling builds.

Meanwhile I will be setting up a subset of the pool to take care of doing Try builds.

I will give another status update when something new happens.
If you want to be up-to-date on all details please follow bug 558448 [1].
You can read my previous post for background information and

[1] Bug 558448 - (support-win64) [Tracking bug] officially support Windows 64-bit builds

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Go Faster: improved download times for test jobs and merged few talos suites together

noreply@blogger.com (Armen Zambrano G.) — Wed, 17 Aug 2011 21:03:00 +0000

As part of the Go Faster initiative I have been involved with a couple of bugs that have now recently gone live.

The first one is establishing a p2p link between two of our colos which improved the download times of builds, symbols and test packages to the test slaves. [1]

We can see in the diagram how the average setup time (which download times are part of) has stabilized after IT enabled the p2p link was enabled last Tuesday Aug. 9th in between our collocations. This means that we have faster download times per run and proportionally more time is spent running tests. This makes our jobs to take less time and increases our pool's capacity. Unfortunately, this also is causing some builds to fail to upload artifacts to ftp (bug 677348). IT has a plan to fix this.

On the other hand, I have merged three talos jobs into only one (this went live yesterday Aug. 16th) [2]. This means that we have removed 2 setup times plus 2 reboot times per push. This is minimal but it gets us started to do more of the same.
Our goal is that every talos suites that takes less than 10 minutes should be joined with other jobs as long as they don't take over 30 minutes. In other words, keep every talos job within 10 and 30 minutes (initial goal).
You probably won't be able to tell that this changed as you will still be able to see the email regressions showing up on the dev.tree-management list. The only difference is that there will be two less "T" jobs per push on tbpl and when you click on a "chrome" talos job you will see the a11y and tscoll suites show up in the summary like this:

tsspider: 11.68 (details)
tdhtml: 538.94 (details)
a11y: 273.5 (details)
ts: 411.26 (details)
ts_shutdown: 328.32 (details)
tscroll: 11582.2 (details)

Now I will gather new data and determine which other suites are to be merged together.
I previously gathered some data and analyzed but I guess I did not write a blog post but just made a comment in a bug.

Stay tuned for more information!

[1] Bug 661656 - Determine if we can improve the download times between sjc1 and scl1
[2] Bug 659328 - Merge talos suites that finish in less than 10 minutes to improve wait times

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Firefox and Windows 64-bit builds (testing version; not a release version)

noreply@blogger.com (Armen Zambrano G.) — Tue, 12 Jul 2011 18:37:00 +0000

We now have a small set of Windows 2008 64-bit slaves ready to be put in our production systems that can generate the 64-bit version of Mozilla Firefox.

NOTE: This is not a released version but a testing version.

I will leave out any talking about when this could be released to our users and just focus on explaining where the project has been and where we are now from a Release Engineering point of view. Releasing depends on evaluating what the problems are on the product side before we would release it.
If you have done any comparison of the pros/cons of the 32-bit and 64-bit version of Firefox running on a 64-bit machine please let me know as I am interested to know.

Try it out
We have been producing Firefox 64-bit nightly builds since last week but we now have a small pool of machines and we are upstreaming the process to production levels.

You can give it a try by downloading the installer.

Help needed
Right now I have several bugs that I need help from developers to get them fixed.

bug 671000 - make buildsymbols takes 45 mins rather than 5 mins
bug 669384 - make buildsymbols fails for leak test builds
bug 670915 - make package fails for leak test builds
bug 670697 - sporadic make check failures

There are many more bugs but the ones I mentioned are the ones that affect releng infrastructure.
We are using a tracking bug for product problems and another one for releng problems.

Background
I started working on this project last year on Q2 and by May 2010 I had some proof of concept going on. To my surprise the media picked up on this and brought a lot of attention to it.
By Q3 we started having problems with OPSI (a system to deploy changes to our machines) and all efforts started little by little shifting towards supporting developers to ship Firefox 4. On Q2 of this year all focus was to adapt to the new fast release cadence.

Nevertheless, by the end of March I had set up a machine to be cloned unto other machines.
Unfortunately the tools that we had in IT were not being able to clone the machine.
IT at that point started to look for a solution and in June we hired digipengi who has Windows experience (for real!).
We worked together and we had to recreate the Windows 64-bit machine from scratch with only one partition rather than three.
We are now at the point that we have 5 production slaves, another 4 to be added soon and we will be cloning the remaining ones in the near future.

If you want to know more CC yourself to the tracking bug.

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

disabling tp4

noreply@blogger.com (Armen Zambrano G.) — Mon, 27 Jun 2011 15:59:00 +0000

As announced on last week's platform meeting, this week we would like to disable tp4 as we have been running tp5 side by side and without issues*.

We have not heard any concerns on disabling tp4 so we will do so on Thursday June 30th.

If you have anything to add please do so at bug 664831.

* The only issues were to adjust tbpl and compare-locales to show tp5 which are fixed

This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.