As I mentioned earlier in this year, I have had the pleasure of working with Vaibhav. Now that time has passed he continues to contribute to Mozilla, and he will be participating this year in Google Summer of Code with Mozilla. I am excited.
I remember right before the winter break where I was off for a couple of weeks to end the year, A new person showed up and started working on some of my bugs. This was Vikas and he was eager and motivated to do a lot of great things. Fast forward to today, and I still chat with Vikas weekly in irc. When he gets a break from school and other activities of interest, he will be hunting for bugs to fix and usually knocking them out 3 or 4 at a time. In fact, I was surprised when I did a query on bugzilla, and on github to see that he is involved in a variety of projects at Mozilla such as Phonebook, Marionette, Talos, and test automation.
I wanted to learn more about Vikas, so I asked him some questions
Tell me about where you live?
Currently I live in Goa, India which is famous for its beaches and attracts many tourists from both India as well as foreign nationals. The best thing about this place is my campus which feels like a home away from home now. I like this place for its beautiful weather, its beaches and ever friendly nature of people living here. This place has brought a lot of changes in my personality and has given me a chance to make some new friends who are always ready to help.
Tell me about your school?
I am a first year undergraduate student at Birla Institute of Technology and Science Pilani, Goa Campus (popularly known as BITS Pilani Goa) pursuing Msc.(Hons) Economics. I am enrolled in a dual degree scheme offered by my college where in I get an option to take a B.E degree depending on my first year’s performance and I hope to get a C.S major. My favorite subject so far has been Computer Science as I’ve always been fascinated towards computers and love to code
How did you get involved with Mozilla?
My first interaction with the Mozilla community was when I started using firefox few years back. Last December I decided to start contributing to some open source organizations and searched for organizations to start with and decided to go with Mozilla. I started with Mozilla since its a very large community so there’s always lots of help available. My experience with Mozilla community so far has been absolutely great, I had no idea how the open source community works and was afraid to ask silly questions as I thought people wont have time to answer those questions. I remember when I was assigned my first bug and Joel Maher was my mentor, while setting the local environment I kept on getting errors and used to pastebin those to him and it took me hours to set it up but he was totally cool with it even though I myself was annoyed with those ever lasting errors. Even now I get stuck at some places but he’s always there to help me. Besides him there are other members too who have helped a lot and are always ready to help if required. My experience so far has been brilliant and am looking forward to learning new things and meeting some great people in the future as well.
What hobbies and activities do you enjoy doing?
Nowadays I spend most of my time coding and learning new stuff. I love the concept of open source software and love to interact with the community and gain valuable experience. Besides coding I enjoy playing football, cricket, and am a complete movie buff. I also love to hang out with friends and spend time with them.
Where do you see yourself in 5 years?
Down the lane in 5 years I see myself as a software engineer working for Mozilla (preferably in the Ateam) solving problems and developing new tools.
What advice would you give someone?
Although I don’t see myself as someone who can advise about life but If someone asked me I’ll advise him/her to enjoy life to the fullest and do whatever he/she loves to do no matter what others expect them to do and if they are related to the software industry obviously I’ll advise them to contribute to the open source community :)
I have enjoyed watching Vikas learn his way around Mozilla. If you have worked with him, you probably already know why I have enjoyed my interactions with him, if you haven’t had the chance to work with him, say hi in irc, his nick is :mishravikas.
On Friday we rolled out a big change to split up our browser-chrome tests. It started out as a great idea to split the devtools out into their own suite, then after testing, we ended up chunking the remaining browser chrome tests into 3 chunks.
No more 200 minute wait times, in fact we probably are running too many chunks. A lot of heavy lifting took place, a lot of it in releng from Armen and Ben, and much work from Gavin and RyanVM who pushed hard and proposed great ideas to see this through.
What is next?
There are a few more test cases to fix and to get all these changes on Aurora. We have more work we want to do (lower priority) on running the tests differently to help isolate issues where one test affects another test.
In the next few weeks I want to put together a list of projects and bugs that we can work on to make our tests more useful and reliable. Stay tuned!
Working at Mozilla, I get to see a lot of great things. One of them is collaborating with my team (as we are almost all remoties) and I have been doing that for almost 6 years. Sometime around 3 years ago we switch to using Vidyo as a way to communicate in meetings. This is great, we can see and hear each other. Unfortunately heartbleed came out and affects Mozilla’s Vidyo servers. So yesterday and today we have been without Vidyo.
Now I am getting meeting cancellation notices, why are we cancelling meetings? Did meetings not happen 3 years ago? Mozilla actually creates an operating system for a … phone. In fact our old teleconferencing system is still in place. I thought about this earlier today and wondered why we are cancelling meetings. Personally I always put Vidyo in the background during meetings and keep IRC in the foreground. Am I a minority?
I am not advocating for scrapping Vidyo, instead I would like to attend meetings, and if we find they cannot be held without Vidyo, we should cancel them (and not reschedule them).
Meetings existed before Vidyo and Open Source existed before GitHub, we don’t need the latest and greatest things to function in life. Pick up a phone and discuss what needs to be discussed.
The last 2 weeks I have gone head first into a world of resolving some issues with our mochitest browser-chrome tests with RyanVM, Armen, and the help of Gavin and many developers who are fixing problems left and right.
There are 3 projects I have been focusing on:
1) Moving our Linux debug browser chrome tests off our old fedora slaves in a datacenter and running them on ec2 slave instances, in bug 987892.
These are live and green on all Firefox 29, 30, and 31 trees! More work is needed for Firefox-28 and ESR-24 which should be wrapped up this week. Next week we can stop running all linux unittests on fedora slaves.
2) Splitting all the developer tools tests out of the browser-chrome suite into their own suite in bug 984930.
browser-chrome tests have been a thorn in the side of the sheriff team for many months. More and more the rapidly growing features and tests of developer tools have been causing the entire browser-chrome suite to fail, in cases of debug to run for hours. Splitting this out gives us a small shield of isolation. In fact, we have this running well on Cedar, we are pushing hard to have this rolled out to our production and development branches by the end of this week!
3) Splitting the remaining browser chrome tests into 3 chunks, in bug 819963.
Just like the developer tools, we have been running browser-chrome in 3 chunks on Cedar. With just 7 tests disabled, we are very green and consistently green.
While there are a lot of other changes going on under the hood, what will be seen by next week on your favorite branch of Firefox will be:
- ‘dt’ jobs for opt, and ‘dt1′, ‘dt2′, ‘dt3′ jobs for debug
- ‘bc’ job will turn into ‘bc1′, ‘bc2′, ‘bc3′
- much faster turnaround times on bc tests (62 minutes is the slowest right now, the rest are averaging ~20 minutes/job)
- less random orange cluttering up results
Talos is the framework used for desktop Firefox to measure performance for every patch that gets checked in. Running tests for every checkin on every platform is great, but who looks at the results?
As I mentioned in a previous blog post, I have been looking at the alerts which are posted to dev.tree-management, and taking action on them if necessary. I will save discussing my alert manager tool for another day. One great thing about our alert system is that we send an email to the original patch author if we can determine who it is. What is great is many developers already take note of this and take actions on their own. I see many patches backed out or discussed with no one but the developer initiating the action.
So why do we need a Talos alert sheriff? For the main reason that not even half of the regressions are acted upon. There are valid reasons for this (wrong patch identified, noisy data, doesn’t seem related to the patch) and of course many regressions are ignored due to lack of time. When I started filing bugs 6 months ago, I incorrectly assumed all of them would be fixed or resolved as wontfix for a valid reason. This happens for most of the bugs, but many regressions get forgotten about.
When we did the uplift of Firefox 30 from mozilla-central to mozilla-aurora, we saw 26 regression alerts come in and 4 improvement alerts. This prompted us to revisit the process of what we were doing and what could be done better. Here are some of the new things we will be doing:
- For all regressions found, attempt to find the original bug and reopen/comment in the bug
- For some regressions that it is not easy to find the original bug, we will open a new bug
- All bugs that have regression information will be marked as blocking a new tracking bug
- For each release we will create a new tracking bug for all regressions
- After an uplift from central->aurora, we will ensure we have all alerts mapped to existing regressions
As this process goes through a cycle or two, we will refine it to ensure we have less noise for developers and more accuracy in tracking regressions faster
Of all the tests that are run on tbpl, mochitests are the last ones to receive manifests. As of this morning, we have landed all the changes that we can to have all our tests defined in mochitest.ini files and have removed the entries in b2g*.json, by putting entries in the appropriate mochitest.ini files.
Ahal, has done a good job of outlining what this means for b2g in his post. As mentioned there, this work was done by a dedicated community member :vaibhav1994 as he continues to write patches, investigate failures, and repeat until success.
For those interested in the next steps, we are looking forward to removing our build time filtering and start filtering tests at runtime. This work is being done by billm in bug 938019. Once that is landed we can start querying which tests are enabled/disabled per platform and track that over time!