Mozilla

Autophone is an automated system that executes Python test scripts on real user hardware, that is, actual phones. It’s been an active project for about a year now, and we’ve learned a lot about the difficulties of performing automated performance measurements on hardware that was never intended for automation. I’m documenting this story for posterity, since it has been an interesting, if often frustrating, experience. If you want to follow along, the source is on github. ...

I bet that the moment most people decide they actually do like git is when they start using ‘rebase’ regularly. I definitely do not completely understand the git model, but rebase shows that there is some seriously cool stuff going on. Anyway, I’ve come upon a rebasing dilemma. The reasons for not rebasing a public repo are clear, but pushing to a remote origin (e.g. github) is also a form of backup. My master branches are for collaboration, but my dev branches are essentially just to back up my home computer, and occasionally for feedback. I rebase dev branches regularly, to keep my commits together for eventual merging to master. I occasionally switch around or squash commits too, where it adds clarity to the history. So, somewhat shamefully, I find myself using ‘git push -f’ a lot on branches other than master. ...

Keeping wiki pages up to date is a hard problem, but recently we found out that people were having trouble finding out what projects we were working on. Obviously we can’t help people with their problems if they can’t figure out what we do, so I spent some time today updating the A-Team’s Project Central. All the projects we are working on are there, along with owners’ IRC nicks and links to project pages and/or docs. We also have links to our quarterly goals as well as to SmartSheet pages with details of our progress. ...

An amusingly frequent pattern: git clone https://github.com/mozilla/new-python-project # ... right, virtualenv mkdir src mv new-python-project src virtualenv new-python-project cd new-python-project mv ../src . . bin/activate # get to work I really ought to make a script to clone new Python projects…

Thanks to dkl, bmo now has an extension which shows a failure data for intermittent-orange bugs. You’ll have to enable the extension by going to the Preferences page and changing “When viewing a bug, show its corresponding Orange Factor page” to “On”. Then the next time you are viewing a bug about an intermittent orange, e.g. the current top orange, bug 789003, at the bottom right of the metadata you should see a sparkline and a count of the failures over the last week, plus a link to its OrangeFactor page. Note that the sparkline corresponds to the failure count, not to the Orange Factor (ratio of failures to test runs). If you think the latter would be more useful, let me or dkl know—it’s an easy change. ...