Category Archives: Uncategorized

Say hi to Gabriel Machado- a newer contributor on the Perfherder project

Earlier this summer, I got an email from Gabriel asking how he could get involved in Automation and Tools projects at Mozilla.  This was really cool and I was excited to see Gabriel join the Mozilla Community.  Gabriel is knows as :goma on IRC and based on his interests and projects with mentors  available, hacking on TreeHerder was a good fit.  Gabriel also worked on some test cases for the Firefox-UI-Tests.  You can see the list of bugs he has been involved with and check him out on Github.

While it is great to see a contributor become more comfortable in their programming skills, it is even better to get to know the people you are working with.  As I have done before, I would like to take a moment to introduce Gabriel and let him do the talking:

Tell us about where you live –

I lived in Durham-UK since last year, where I was doing an exchange program. About Durham I can say that is a lovely place, it has a nice weather, kind people, beautiful castles and a stunning “medieval ambient”.  Besides it is a student city, with several parties and cultural activities.

I moved back to Brazil 3 days ago, and next week I’ll move to the city of Ouro Preto to finish my undergrad course. Ouro Preto is another beautiful historical city, very similar to Durham in some sense. It is a small town with a good university and stunning landmarks. It’s a really great place, designated a world heritage site by UNESCO.

Tell us about your school –

In 2 weeks I’ll begin my third year in Computer Science at UFOP(Federal University of Ouro Preto). It is a really good place to study computer science, with several different research groups. In my second year I earned a scholarship from the Brazilian Government to study in the UK. So, I studied my second year at Durham University. Durham is a really great university, very traditional and it has a great infra-structure. Besides, they filmed several Harry Potter scenes there :P

Tell us about getting involved with Mozilla –

In 2014 I was looking for some open source project to contribute with when I found the Mozilla Contributing Guide. It is a really nice guide and helped me a lot. I worked on some minors bugs during the year. In July of 2015, as part of my scholarship to study in the UK, I was supposed to do a small final project and I decided to work with some open source project, instead of an academic research. I contacted jmaher by email and asked him about it. He answered me really kindly and guided me to contribute with the Treeherder. Since then, I’ve been working with the A-Team folks, working with Treeherder and Firefox-Ui-Tests.

I think Mozilla does a really nice job helping new contributors, even the new ones without experience like me. I used to think that I should be a great hacker, with tons of programming knowledge to contribute with an open source project. Now, I think that contributing with an open source project is a nice way to become a great hacker with tons of programming knowledge

Tell us what you enjoy doing –

I really enjoy computers. Usually I spent my spare time testing new operating systems, window managers or improving my Vim. Apart from that, I love music. Specially instrumental.  I play guitar, bass, harmonica and drums and I really love composing songs. You can listen some of my instrumental musics here:

Besides, I love travelling and meeting people from different cultures. I really like talking about small particularities of different languages.

Where do you see yourself in 5 years?

I hope be a software engineer, working with great and interesting problems and contributing for a better (and free) Internet.

If somebody asked you for advice about life, what would you say?

Peace and happiness comes from within, do not seek it without.

Please say hi to :goma on irc in #treeherder or #ateam.

Leave a comment

Filed under Uncategorized

DX Contribution Program – Wrap up

This summer went by fast.  Back in May we announced the opportunity to participate in the DX project.  In June we announced the team.  August ended and the project officially came to a halt.  First off, I would really like to thank all the participants who took interest in this program.  With 5 eager hackers, there is a lot to do!  As the summer wore on, some folks got side tracked, others worked when they could and some kept moving forward.  No matter what the outcome, I do applaud the 5 great contributors who spent their free time getting setup and started on a project.

Now that we are at the end, I would like to outline some of the work that was done and things that were learned.

A few great things got started like mach usage statistics, and Marionette harness cleanup.  These are not easy to get started on and figure out all the quirks with our full scale ecosystem.  It is wonderful to see ideas and progress being made.   Thanks BYK and sehgalvibhor.

Two other projects didn’t get much traction.  While I like to blame myself as a mentor (yes, I could have done a bit more or scoped the projects differently), we ended up not making progress on a few projects.  This is OK, and there is always stuff to learn.  On the projects that didn’t get going, I saw gma_fav struggle a bit, but persist.  I know the right project is out there and she will succeed next time, ideally at Mozilla!  I enjoyed learning about wunderlist from stanley, and will look forward to more of his enthusiasm.

The last project is run-by-dir.  kaustabh93 really worked consistently on this and learned a lot about working in the mozilla-central tree, using try, and understanding our infrastructure.  A lot of work was done for mochitest-plain and mochitest-chrome.  He is still hacking away and making fast progress.  As Kaustabh was the only contributor who was consistent throughout the entire program, I wanted to hear his perspective on the program:

How did you hear about the program, why were you interested?
I had been a contributor at Mozilla for quite sometime working mainly on AlertManager and familiarizing myself with Mochitests by means of solving bugs and reading code. It was at this time, that my curriculum needed me to do an industrial project (internships/training/other programs for which the company would acknowledge mt work by means of certificates or letters or both). I brought this up with my mentor and a few days later, he informed me about this program.
It had been an awesome experience coding for Mozilla so far & hence I got interested instantly.
What did you find challenging?  How did you overcome these challenges?
The existing volume of codes were huge and getting to know what is what was challenging. I overcame this by solving smaller bugs first and reading codes and of course a lot of help, advice & explanation from my mentor, jmaher. He is an awesome person and one of the best mentors, I’ve known.

What advice would you give for anybody looking to contribute in this program?

People looking to contribute to this program should get involved in coding for Mozilla some time prior to commencement of this program. That way they can be familiarized with the existing codes and can better understand their work and this way, they can make the maximum impact with their work. And they should continue contributing to Mozilla even after this program closes.
Other thoughts : One more thing that I should advice people regarding this program is that if they contribute to Mozilla just for this programs (contribution start and end dates coincides with that of the program), then they’re probably doing it wrong.

While I appreciate the callout as a great mentor, there are many other great Mozillian mentors, it is my pleasure to work with folks who contribute their free time to the project,

Without making this too long, I did learn a lot from this great group of participants.  A few tips for becoming a better mentor (you get better with experience and learn from mistakes) is to communicate regularly with whom you are mentoring, this should be at least twice a week.  While mentoring involves a lot of encouragement and gentle guidance, it is important to listen more to what roadblocks are in place (schedules, technical, etc.) and sometimes we need to move to a smaller or simpler project until the timing is right for the big project.  One other big callout was that gma_fav was helpful in making me really understand how our use of master/slave is offensive to many, I am glad I listened to her and worked with her for a couple months!

I look forward to watching these contributors grow outside of this program and meeting more great folks!

Leave a comment

Filed under Uncategorized

Lost in data – episode 2 – bisecting and comparing

This week on Lost in Data, we tackle yet another pile of alerts.  This time we have a set of changes which landed together and we push to try for bisection.  In addition we have an e10s only failure which happened when we broke talos uploading to perfherder.  See how I get one step closer to figuring out the root cause of the regressions.

Leave a comment

Filed under Uncategorized

lost in data – episode 1, tackling a bunch of alerts

Today I recorded a session of me investigating talos alerts, It is ~35 minutes, sort of long, but doable in the background whilst grabbing breakfast or lunch!

I am looking forward to more sessions and answering questions that come up.

Leave a comment

Filed under Uncategorized

re-triggering for a [root] cause- version 2.0 – a single bug!

Today the orange factor email came out- the top 10 bugs with stars on them :)  Last week we had no bugs that we could take action on, and the week before we had a few bugs to take action on.

This week I looked at each bug again, annotated them with some notes as to what I did or why I didn’t do anything, here are the bugs:

  • Bug 1160008 Intermittent testVideoDiscovery
    • too old!  (from last week)
  • Bug 1073442 Intermittent command timed out
    • too old; infra issue (from week before last)
  • Bug 1121145 Intermittent browser_panel_toggle.js
    • too old!  problem got worse on April 24th (from last week)
  • Bug 1157948 DMError: Non-zero return code for command
    • too old!  most likely a harness/infra issue (from last week)
  • Bug 1161817 Intermittent browser_timeline-waterfall-sidebar.js
    • fixed already
  • Bug 1168747 Intermittent 336736-1a.html
    • resolved (via skip-if in manifest)
  • Bug 1149955 Intermittent Win8-PGO
    • too old (from last week – someone looking into it now though!)
  • Bug 1158887 Intermittent test_async_transactions.js
    • reopened – fix landed recently- re-triggering doesn’t seem helpful :(
  • Bug 1090203 Intermittent style-src-3_2.html
    • to do work
  • Bug 1081925 Intermittent browser_popup_blocker.js
    • test is disabled now (from last week)

It is nice to find a bug that we can take action on.  What is interesting is the bug has been around for a while, but we noticed about May 21 that the rate of failures went up from a couple a day to >5/day.  Details:

  • started out re-triggering on m-c.  We could see a pattern on a specific merge.
  • did re-triggers on m-i.  20 was inconclusive, and then triggered 20 more for each job- the results were still inconclusive.  There is no increasing pattern based on a specific chanageset.

I might try a full experiment soon blindly looking at bugs instead of using orange factor.

Leave a comment

Filed under Uncategorized

re-triggering for a [root] cause – version 1.57

Last week I wrote some notes about re-triggering jobs to find a root cause.  This week I decided to look at the orange factor email of the top 10 bugs and see how I could help.  Looking at each of the 10 bugs, I had 3 worth investigating and 7 I ignored.


  • Bug 1163911 test_viewport_resize.html – new test which was added 15 revisions back from the first instance in the bug.  The sheriffs had already worked to get this test disabled prior to my results coming in!
  • Bug 1081925 browser_popup_blocker.js – previous test in the directory was modified to work in e10s 4 revisions back from the first instance reported in the bug, causing this to fail
  • Bug 1118277 browser_popup_blocker.js (different symptom, same test pattern and root cause as bug 1081925)


  • Bug 1073442 – Intermittent command timed out; might not be code related and >30 days of history.
  • Bug 1096302test_collapse.html | Test timed out. >30 days of history.
  • Bug 1151786 testOfflinePage. >30 days of history. (and a patch exists).
  • Bug 1145199 browser_referrer_open_link_in_private.js. >30 days of history.
  • Bug 1073761 test_value_storage.html. >30 days of history.
  • Bug 1161537 test_dev_mode_activity.html. resolved (a result from the previous bisection experiment).
  • Bug 1153454 browser_tabfocus.js. >30 days of history.

Looking at the bugs of interest, I jumped right in in retriggering.  This time around I did 20 retriggers for the original changeset, then went back to 30 revisions (every 5th) doing the same thing.  Effectively this was doing 20 retriggers for the 0, 5th, 10th, 15th, 20th, 25th, and 30th revisions in the history list (140 retriggers).

I ran into issues doing this, specifically on Bug 1073761.  The reason why is that for about 7 revisions in history the windows 8 builds failed!  Luckily the builds finished enough to get a binary+tests package so we could run tests, but mozci didn’t understand that the build was available.  That required some manual retriggering.  Actually a few cases on both retriggers were actual build failures which resulted in having to manually pick a different revision to retrigger on.  This was fairly easy to then run my tool again and fill in the 4 missing revisions using slightly different mozci parameters.

This was a bit frustrating as there was a lot of manual digging and retriggering due to build failures.  Luckily 2 of the top 10 bugs are the same root cause and we figured it out.  Including irc chatter and this blog post, I have roughly 3 hours invested into this experiment.

Leave a comment

Filed under Uncategorized

Alert Manager has a more documentation and a roadmap

I have been using alert manager for a few months to help me track performance regressions. It is time to take it to the next level and increase productivity with it.

Yesterday I created a wiki page outlining the project. Today I filed a bug of bugs to outline my roadmap.

Basically we have:
* a bunch of little UI polish bugs
* some optimizations
* addition of reporting
* more work flow for easier management and investigations

In the near future we will work on making this work for high resolution alerts (i.e. each page that we load in talos collects numbers and we need to figure out how to track regressions on those instead of the highly summarized version of a collection).

Thanks for looking at this, improving tools always allows for higher quality work.

Leave a comment

Filed under Uncategorized