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.

I guess I could get a paid account and fork private dev repos, but branches seem a lot more convenient, and I don’t really want to hide anything from anyone, as embarrasing as some of my work in progress sometimes seems to me.

Maybe the moral of this story is “never pull from my dev branches”?

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.

We’ll do our best to keep it up to date!

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…

EDIT: Sorry, the image links were broken everywhere but on the main page of my blog. Fixed now. Still getting used to Octopress. :)

It’s been a while since I last wrote about it, but the A-Team is still maintaining the SpeedTests framework, gathering the results of a few different benchmarks on all the major browsers on a 32-bit Windows 7 installation. I haven’t had any time to add new tests, but I made sure to keep the results coming in for the tests we do have.

With IonMonkey having landed a couple weeks ago, I expected to see some big improvements. Sure enough, we can see a big jump in Kraken, as David Anderson saw:

That’s about a 27% improvement, right about what David measured on his machine. That makes Firefox about 16% faster than Chrome 21 (which itself improved by about 6% from Chrome 20).

As for V8,

The data is a bit noisy, but it looks like an improvement of around 9-10% on the overall results (geometric mean of the total test results). Not as much of an improvement, and Chrome is still 25% better, overall.

The “Speed” Tests also run (a sort of old version of) test262, a conformance suite:

No changes there, which is what we would expect.

I looked through the other tests, and it doesn’t look like IonMonkey has made much of a difference. But of course all these tests are very specific and/or artificial. If there are any JavaScript-based tests that should show clear improvements, feel free to let me know and maybe I’ll find the time to add them!

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.

Bugs can be filed under bugzilla.mozilla.org | Extensions: OrangeFactor.