Categories
Mozilla

Double Landings? No Problem!

I just found a really useful way to do the double landings that we have to do if we want to land anything on the 1.9.1 branch right now. hg has this handy feature that will let you import from a url, which means it’s incredibly simple to take a changeset from mozilla-central, and then push it to mozilla-1.9.1:

  1. Figure out your changeset url for mozilla-central. For this example, we’ll use http://hg.mozilla.org/mozilla-central/rev/242894260a86.
  2. In your mozilla-1.9.1 tree, run hg import and pass in the previously obtained mozilla-central revision url, with a minor modification: change rev to raw-rev (so you’ll end up with http://hg.mozilla.org/mozilla-central/raw-rev/242894260a86

Assuming it applied cleanly, you now have that changeset as a local commit in your repo. You can now push like you always do. Happy landings!

Categories
Mozilla Personal

Artistic Blog Representation

I wanted to see what I was writing about looked like after reading KaiRo’s post about his site. So, I jumped on over to Wordle (which sadly uses Java), and generated this:


Click to see full image

Clearly, I write a lot about Mozilla, and as of late, performance has dominated that topic. It’s funny, because some time this week I was going to write another blog post about performance too…

Side note: It’d be really cool if someone made a WordPress widget that generated this.

Categories
Personal

WordPress Upgraded and a New Theme

I just got done upgrading WordPress again. I was a bit out of date, but no longer! I also got tired of iTheme, so I’ve gone and grabbed Whitespace by Brian Gardner. I’m not totally happy with it, so I expect to be making some modifications, but I like it a lot better than iTheme.

Let me know if anything seems broken…

Categories
Mozilla Technology

Highlight Warnings in Make

Curtis just gave me this incredibly handy piece of code that higlights errors and warnings in make output. Now, when I’m building, all the warnings are highlighted in yellow, and the errors in red. Just put the following in your bash profile script:

make()
{
  pathpat="(/[^/]*)+:[0-9]+"
  ccred=$(echo -e "\033[0;31m")
  ccyellow=$(echo -e "\033[0;33m")
  ccend=$(echo -e "\033[0m")
  /usr/bin/make "$@" 2>&1 | sed -E -e "/[Ee]rror[: ]/ s%$pathpat%$ccred&$ccend%g" -e "/[Ww]arning[: ]/ s%$pathpat%$ccyellow&$ccend%g"
  return ${PIPESTATUS[0]}
}

Of course, improvements and more ideas welcome! Thanks goes to Curtis for this!

Categories
Mozilla

Performance Regressions are Painful

I think it is a well known fact that performance regressions are really painful. They cause pain on more than one front too! You have users who have a less responsive application, drivers who have to figure out who and what caused the regression, and developers who have to backout or come up with a fix for the regression.

Until recently, we only had a heavy handed tool (the graph server) that is slow and painful to use. Recently, Johnathan has revamped his performance dashboard which is a very quick and easy way for people to see the current status of some of the more important performance graphs (it’s also easy to hack on!). This has made spotting a regression much easier and faster, which great increases the odds of the offending change(s) being backed out. The longer a performance bug is left in the tree, the harder it becomes to do a straight backout.

Today I decided I was going to spend the day eliminating the rest of our open performance bugs (or make sure they had blocking requested for the current release). However, I was amazed at how many old performance bugs we had open that hadn’t been touched in six months or more. I probably closed about 20 bugs as INCOMPLETE since there was virtually no way we were going to be able fix those bugs anymore. One bug I was actually able to mark as FIXED, and there were a few more that were recent regressions that I posted comments on to make sure people were still working on.

This made me realize that we have a serious problem though. We currently have no way for people who care about performance regressions to easily be aware of new bugs filed. To help this, I went ahead and filed bug 467170 which will allow folks to add an e-mail address to the cc list of all performance regression bugs so the folks who care about this can watch the address and get mail about these issues. Once bug 464609 gets resolved the sheriffs will also have a place to bring these issues up so the next sheriff is aware of what is going on as well.

I think we are starting to move in the right direction when it comes to performance monitoring, but I think we also have a long ways to go. Remember kids, only you can help stop performance regressions.