Saurabh Anand

My First Talk

It’s been some time since I’ve posted anything here but recently I’ve been to places which have given me enough to talk about :P

So while roaming around the IRCland, I get this ping from Sankha, saying that I should come give a talk at the Mozboot event at Ignus’13, the cultural fest of IIT Jodhpur. I was flabbergasted. I mean a request to fix a bug or go help a newcomer is something I’ve expected but giving a talk, woah! But I said yes anyways, lured by the prospect of getting to visit Jodhpur (which I must say is a beautiful city, you must check it out) but at the same time a little nervous about whether I would be able to do justice to the event. I told Sankha that this would be my first talk and that I probably wouldn’t have much idea what to talk about but he seemed pretty confident in me. So I decided to give it a shot.

In the meanwhile FOSDEM happened in which Josh happened to give a talk which had very well prepared slides so rather than reinventing the wheel, I decided to use them.

The event had a pretty decent crowd. The students were attentive and weren’t just busy browsing around (well atleast most of them weren’t :P). I started by talking about Open Source and why it’s great to contribute to any open source organization. I highlighted the benefits of open source contributions. I then moved on to why contribute to Mozilla, the impact of your contribution and my experience when I started up. Since I mostly contribute to the core Firefox browser I was mostly focused on how to do that, however I guided them to the resources which might help them if they needed more information about contributing to some other Mozilla project.

Then we took a break in which other Open Source folks took over the stage and introduced the participants about Django, Python and Open Source. I thought that in order to get people to actually do something meaningful, we needed to make the session more hands on. So in the second session of ours, we started getting people who had Linux installed, to install the build prerequisites of Firefox. We went around and helped the people who faced any problems. After that most of them started their compilations which took a lot of time. In the meantime we asked them to go through bugsahoy and find bugs which interest them. Quite a few of them found some interesting bugs and also started looking at the source code to figure out where and how to fix it. Since by that time we had already crossed the time alloted to us, we had to wrap up otherwise who knows, someone might have fixed their first bugs!

I faced a few problems which I’m going to address in the future :

• When quite a lot of them tried to connect to the irc, there was an IP limit enforced by the server. I’ll probably try and find out people who can help me with this, specially on weekends and who work in my timezone, since that’s when most of the talk happen.
• I’ll try and have a way by which I can follow up with the people who attended the talk, maybe by taking their email ids or some other way.

Overall the session was pretty good and top it all, we went to the Mehrangarh fort where Bane used to live (atleast when he was a boy :P).

Landing 101

This post is the result of some glory and shame that I brought upon me this weekend, within very short durations. So as you must be knowing I got L3 access around this weekend (and if you don’t know follow me on twitter — see what I did there) and was quite excited. And pretty soon I decided to try my luck and it turned out Lady Luck was enjoying her weekend at that time. So within minutes of landing my patch I found out that I had to back it out, so I accepted the truth and did what had to be done.

During that time, I learnt a lot of things and have hence decided to share this invaluable knowledge with you. The following is a documentation from what you should do from the moment you get L3 to landing a patch. Hope it helps some other lost souls out there like me. So here it goes :

Notes: I will use m-i and m-c interchangeably for mozilla-inbound and mozilla-central throughout the article. This article also makes use of ample sarcasm, although you might already know that by now.

Path To Ultimate Glory :

1. Stay Calm: This is the most important step, if you are able to do this successfully, you’re already half way through.
2. Be Familiar With The Enemy: Mozilla-Inbound tree rules are a good place to start.
3. Obtaining Mozilla-Inbound: So the most convenient way to land patches is to manage a local mozilla-inbound repository, besides your mozilla-central. I keep my mozilla-central for hacking on my bugs and mozilla-inbound only for pushing patches. One way is to clone the entire repo from Mozilla-Inbound. A second, much easier and faster, way is to clone it from your existing local mozilla-central. So a) Just run this in the directory where you want to clone your m-i : hg clone /path/to/m-c mozilla-inbound Read this post by Justin Lebar for more details b) Run this command inside your local mozilla-inbound repo : hg strip —no-backup ‘roots(outgoing())’
4. Make m-i Push Compatible: Edit your .hg/hgrc inside the local m-i to look like below. Some people prefer to name their push url’s to default-push since that enables them to push by simply issuing hg push compared to hg push inbound (which I have to issue to push) according the below configuration. I prefer the latter since typing inbound just makes sure that I am aware of where I am pushing (and just cautions me to be careful). See |hg help urls|.
   

   [paths]                                                                                               default = https://hg.mozilla.org/integration/mozilla-inbound                        inbound = ssh://hg.mozilla.org/integration/mozilla-inbound

5. Pull The Latest Changes: Runhg pull -uin your local m-i to pull the latest changes from the remote mozilla-inbound repo and update it.
6. Import the Patch: Import the patch or mercurial queue that you want to push. In most cases I simply do :hg qimport ../mozilla-central/.hg/patches/name_of_queue_to_importsince my latest patches in my local m-c.
7. Apply the Patch: Simply do :hg qpush —move name_of_patch_to_push
8. Move Applied Patches Into Repository History: Run hg qfinish -aThis takes your patch from mercurial queues to out of it’s control and into the actual repo. See |hg qfinish —help| for more details.
9. Push: Runhg push inboundIf it spits out a url, then everything has gone according to plan, then simply just go and paste that url to the concerned bug for record keeping and so that other are aware of your push. Now your work is done, young grasshopper. Go outside, have some fun. However, if no url’s were printed, you might just have to do carry out a few more steps.
10. Do this only if the push wasn’t successful in the previous step: The failure just means that someone else has pushed between you pulling and pushing. Runhg qimport -r tipThis just converts your change to the repo back to a mq. Then runhg qpopto pop off that mq. Repeat steps5,7,8,9until you succeed.
11. That’s it! You just landed your first patch….now go fix some more, you slacker ;)

In The Face Of Danger :

• Stay Calm: Staying calm is the key to inner happiness, doesn’t matter if you’ve just burnt the tree, it’s all cool my friend.

• IRC : Join the #developers or #introduction on irc.mozilla.org and ask someone for help. There are a lot of helpful and knowledgeable folks over there, they will surely know what to do.
• Backout : If you know what caused this problem, then simply back out your push. You can also use this nice backout extension by Steve Fink for mercurial, by doing the follows :

1. Download the __init__.py from the repository. Save it in a convenient location.
2. Go to your hgrc (in my case /etc/mercurial/hgrc), add this to it under the section called “[extensions]” : qbackout = /path/to/init.py. Save it and close it.
3. Run hg qbackout -r revnum from your local mozilla-inbound repository. This will create a mercurial queue out of that revision which you backed out. Now you need to push this onto inbound, similar to what you did previously.
4. Qbackout would have created a mq, pop that queue and run hg pull -u in your local mozilla-inbound.
5. hg qpush —move name_of_backout_mq
6. hg qfinish -a
7. hg push inbound
8. When successfully pushed, this will spit out a url, paste that url in the concerned bug in bugzilla so that others also know about it.
9. If push fails, repeat the above step 4,5,6,7 until you succeed.

• Run : Run for your life because no one can save you from being backed out by kyle huey

My Thoughts On Getting L3 Access :

You don’t need to get L3, there are helpful people who will land your patches for you. Only when you feel that, you not having L3 is somehow affecting the speed with which you are fixing bugs, then you should consider it. I initially thought that this would increase my work (since I would have to rebase my bitrotted patches myself before landing :P) but now having landed a few patches (successfully) I feel having L3 is good in a sense, since I can quickly get done with patches (and not keep on checking them hoping someone landed them or requesting people to do the same). Overall it’s satisfactory.

Acknowledgements :

As usual, after messing up I ended up seeking help from our good guy, Josh Matthews and our mystery guy, Ms2ger. Thanks guys for helping me out.

PS : I learnt “rebasing” is just a fancy word for struggling with hg’s stupid habit of bitrotting any changes within 8 lines of yours and *manually* updating the patches. I had been under the impression this would be some kind of an intelligent automated process.

Firefox very close to getting Per-Window Private Browsing

Firefox till now had a very good support for Private Browsing, but it just got better. Now you can work and browse “private” stuff simultaneously, without loosing your tabs or hampering your flow. Finally after waiting for so long, Per-Window Private Browsing is very close to arriving in Firefox. If you want to give it a try, check out  this article by Ehsan and take it for a spin ! So if your boss is breathing down your neck and you need to get work done, while at the same time, need to buy some gifts secretly without leaving any trace, this feature is for you.

This feature had been awaited by people for a very long time[1]. In fact some of them started getting restless (see the comments on that bug). But due to some awesome work by Ehsan Akhgari, Josh Matthews, Chris Lord and yours truly, the feature has finally been implemented to a stage where it can be uplifted to the next channel for more rigorous testing.

Since the other browsers already had this feature, hence it was expected by people that it would be in Firefox too. I personally had wanted this feature for quite some time, and it feels good to have contributed to what I wanted to see. I think this is why I like Open Source and specially Mozilla. I love everything about Mozilla, except the TBPL page showing “Loading 9%” message ;).

So go ahead and try it and I hope you buy lots of “gifts” for your girlfriend,relatives or just yourself ;) . If you don’t get what I mean, read this comment . I would love to hear what you guys plan to do with this :)

Feel free to drop by on twitter to say hi, share your experience about how this bug will change your life or just “bug me about some bug in my bugs” (don’t try and ask me what I just meant by that statement).

Resources :

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

First shot at remixing video with PopCornMaker

I had heard a lot about Popcorn.js and the Popcorn Maker project by Mozilla but never actually got around to playing with it. I was waiting for some excuse to tinker with it and that excuse came yesterday.

We are/were having the MDN Virtual Doc Sprint from Nov. 30 to Dec. 1. I asked around on the irc channel about what I could do and Janet Swisher suggested I do a screencast about how to build firefox on Linux. Since I was on Ubuntu, a lot of good screen recording tools like Camtasia weren’t available on it. I tried gtk-recordmydesktop but for some unknown reason it was rendering choppy videos. Then Janet suggested a nice wiki page which had some nice tips about making screencasts. On that page I found out about Screenr, a Java based solution which was platform independent and pretty sweet. So I started recording. Since this required me to run this process on a clean machine, so that things actually get installed rather than just saying “XYZ is already installed”, which looks lame. After I recorded my screencast, I shared it with Janet, It seemed that the audio was a bit feeble and also I needed to do more speaking during the video. Since I no longer had any clean machines at my disposal and I have no clue how to do video editing, I had no option than to do something with this existing video. That’s when Josh Matthews suggested I do some remixing with Popcorn Maker. This was a nice idea since I could finally get my hands dirty and also improve the video by adding some text and links. Here it is :

Since it’s Popcorn Maker, I would love to remix this and come up with even better version of this.

Overall this was quite a different experience from working on bugs to making screencast and remixing them using PopCorn Maker. Now planning to go help some more in the sprint.

PS : This was also my first YouTube upload.

If you have questions or want to just say hi, feel free to ping me on twitter (@sawrubh) or on the irc (#introduction)