Google Summer of Code, Mozilla

The Grand Finale

header-firefox

This will probably be my last post regarding my Summer of Code with Mozilla, and I imagine if I were writing this with paper and quill, I would indeed have been writing this last entry with a heavy hand.

There exists a saying that tells me “All good things must come to pass”.
Although sadly true, sometimes I wonder if some things are too good to deserve the same fate as all the other good things.

My stint with Mozilla being the case in point. The past 3 months have been immensely enjoyable, full of excitement and activity. I had the pleasure of working with an amazing team of people who work for a noble cause. My stay with the Automation and Tools team has been an enriching experience and one that I shall cherish for a long time.
My writing might convey a sense of parting, but thankfully once introduced to the world of OpenSource one can never truly part.  I hope to be able to stay and contribute to Mozilla in the future as I have in the past.

Since this is the penultimate if not the ultimate post in this series of Summer of Code posts, I feel the need to try and briefly summarize the events of days past.

My Project with Mozilla over the summer consisted of writing tests for Mozbase. Mozbase is a base library used by most of the other test harnesses that are used to automate the installation, logging and testing of the various software products that Mozilla builds, Firefox and FirefoxOS being the most notable.
One by one I picked up the modules in Mozbase and wrote tests for them at the rate of roughly a module per one and a half week.
I must pause here and point out how well planned the schedule for my project was, allowing me enough time to cope with the new code, before handing me slightly more complex modules, and for this I owe a debt of gratitude to Clint Talbert(my mentor for the project) who, basically, had it all figured out.

I started my quest with Mozfile (#885224), which is a cross platform utility to handle file I/O operations. Mozinfo (#885145) came next, this module was a bit of a surprise to me for I hadn’t seen a module like this before. All it literally does is give information about the platform on which it runs, or sometimes simulates information about a different platform for the purposes of testing.

Having worked with, understood and written tests for two modules successfully, I now faced Moznetwork (#796017). This is where I first really ran into what would later become a recurring challenge throughout my project, this challenge goes by various names, sometimes it’s called WindowsError, sometimes another MacOSX only exception, most people know these collectively as Cross-Platform issues. After copious amounts of time and effort were spent, mostly by jhammel, wlach, ahal and Mook who would’ve burst a vein answering my repeated questions had they not been endowed with Monk-like patience, Mozinstall tests finally started working properly. Moznetwork on the other hand was kind towards me, I got to play around with network interfaces and write some regex which is always fun.

On to another network-ish module Mozhttpd (#889709)  which is a simple webserver written in python used for internal testing. Mozhttpd was particularly memorable because it was the only module whose tests failed for me after both a fresh pull and a clone, after debugging I came to know that it was a proxy/environment issue(I access the internet via a proxy, so I have http_proxy variables set everywhere). I’m not sure if I filed a bug for it though, since it’s a weird edge case, lucky me sitting right on that edge :P .

Moznetwork marked the end of the simpler modules, time to meet the heavyweights, Mozdevice(#894062), Mozprofile(), Mozprocess().
Up first was Mozdevice, this was a particularly enjoyable module, I got to muck around with android internals, emulators and adb a bit. Wlach really helped me through this one with lots of tips that were invaluable when I needed to set up the test environment. Being a large module, this one took me more time than the earlier modules, a little over 2 weeks, but by the end of it we had tests for the DeviceManager class.

After wrapping up Mozdevice I moved onto Mozprofile(#898265). Mozprofile is a module that handles almost all firefox profile related tasks, from major profile data to addons. Mozprofile saw me reading through the code more carefully than the other modules, partly because of the tricky cleanup/__del__ procedure and partly because I’d had not so pleasant run-ins with mozprofile in the past. It wasn’t nearly as bad as I’d orginally imagined it would be, and infact turned out to be quite an enjoyable experience. I ended up mostly writing tests for the addons manager. I also found a couple of tiny bugs and filled a few more during the course of my “investigations”, some of which were fixed right away incidentally.

Lastly we come to Mozprocess (#778267). Mozprocess is a monster module in terms of complexity and size (I exaggerate of-course, but yes it’s big and complex). Existing mozprocess tests were written in a mixture of C and python which made them hard to compile and run, especially on the build slaves on Mozilla’s automation infrastructure.
My first task was to try and port the existing C tests to python, or if that didn’t work out rid the existing C tests of the external library dependency making them easier to compile, run and automate. The python porting worked out and I started rewriting all the existing tests to work with the new API that I and jhammel came up with.
The new API allows creating arbitrary process trees, with multiple children each with their own timeouts at each level of depth. Although this might sound fancy, it’s nothing more than a little rewriting of the controlling .ini manifest file. The processlauncher code did require a major rehaul for the new API though. During the process of porting and re-doing proclaunch.py I wrote some of my most beautiful and comprehensive documentation, even if I say so myself. :P
If you’ve been reading carefully, I mentioned my arch Nemesis WindowsError, well guess what? It decided it was about time to drop by while I’m on my final module. Long story short windows tests still fail on Windows and that needs fixing, the *nixs on the other hand are running right as rain.

All code that I’ve produced over the summer has been reviewed by atleast one member of the Automation and Tools team and has been checked into the github repository, which can be found here. All documentation in the code takes place within the code itself, and all checked-in code contains the relevant documentation.

Related misc. fixes and filings:

Standard
Google Summer of Code, Mozilla

The final stretch!

It’s the last week of the Google Summer of Code and I’ve found myself spending more time getting mozprocess tests in shape.
Mozprocess was one of the more challenging modules I’ve dealt with in terms of complexity, but it has also been the most enjoyable.

Cross-platform issues are always a joy, and mozprocess lived upto expectations marvelously ;) .
I came across WindowsError exceptions flying through the stack, like chickens flying the coop. Thankfully the WindowsErrors went away (mostly) and the *nix systems were pretty co-operative this time around.

I now have a respectable patch up, approved and r+’d , with a successful try-run.
So Tyche and Fortuna willing, the patch should land pretty soon.

For the entire story please visit Bug 778267.

Update: Patch landed! :D

Preemptive celebratory photograph:
So much win!

Standard
Google Summer of Code, Mozilla

Guess who’s back?

I haven’t updated this blog since my semester started and that isn’t particularly a good thing.
Thanks to Gerv’s Reminder this blog is now back up and will resume it’s cycle of weekly updates.

Although the blog hasn’t been updated in a while I have been chipping away at Mozprocess little by little.

It’s a module that lends us the ability to kill processes across platforms. Testing involves generating various types of process trees,
And then killing these process trees and checking that this was done correctly.

This endevour doesn’t have it’s own bug number, instead all work is being done under Bug 778267 .
I hope to be back with more updates soon!

Standard
Google Summer of Code, Mozilla

It’s a Six!

Summer of Code - Week 6

The sixth week is over and done with, and I’ve been putting in some time to work on mozprofile.
Mozprofile seemed like a tricky module initially, I’ve been working on testing the AddonsManager code mostly, and it comes with it’s fair share of “Gotcha”s.
It’s not difficult code as such, but it took me more readings than the other modules I’ve worked with, which is not necessarily a bad thing.
As always there’s a bug number associated with the work I’ve been doing, this time it’s 898265 .

Next up is Mozprocess, which is the last module I need to write unit-tests for as per Schedule. After that I’ll be going back and trying to write more tests that I might’ve missed in the past and I’ll be attempting some other slightly trickier stuff, including trying to bundle the Android Emulator so that we can test the SUTAgent. Exciting times!

In other news, The mid-term evaluation results are out, and I happy to inform everyone that I passed my mid-term evaluation. Yay!

Standard
Google Summer of Code, Mozilla

For how fickle can a fifth be?

radio5cropped

“Fie, Fie ffledgling! for having forsaken thy foremost duties again!”. Yes Shakespeare I understand.

As is now becoming a frequent occurrence, this update has been overdue and technically should’ve been out a few days ago, but then again, it has been a fickle fifth week.
Last week was characterized by contradictions and rapid changes. I went from having the fastest internet I’ve had in a while, to nearly no internet for a while. Days in the past week have seen me both at my productive and counter-productive best.

Productive and counter-productive at what you ask? Why my Summer of Code Project ofcourse!
Mozdevice has been an interesting module to work on, but I’ve manged to finish writing all the unit tests I could for it at the moment.

if you really want to take a look at the gory details, there’s always a bug number to help you out, and this time it’s Bug 894062 to the rescue!

I will now be moving on to Mozprofile! As the weeks progress, the modules I work on seem to grow ever so slightly, both in size and complexity, which was what keeps things interesting ;)

Keep an eye out for the next post!

Standard
Google Summer of Code, Mozilla

A fine fourth !

Image

The 4th week of my adventure comes to an end, and I must say it’s been thoroughly enjoyable so far. This week’s work involved working with adb, avds, mozdevice and telnet!

I’ve been writing a few tests for mozdevice, and in the process I’ve been learning a bit about the tools offered by the android-sdk, namely adb and the android emulator. New tools, systems internals and sockets always intrigue me, and this week had all 3! As always the people at ateam have been very helpful, explaining things with patience worthy of a Monk ;)

As always there’s a bug to keep track of my status and progress, and it’s called … Bug 894062! Yes, not very inspiring, I know, but that’s just how bug names are.

Week 5 will see me continue work on Mozdevice tests and hopefully, if I can hurry things up a bit, start work on Mozprofile.

Standard