On Freedom
They may take our land, but they can’t take away our freedom!
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.
My Sacrifice
I did something a bit crazy today. Insane might be a good adjective to describe me here as well. First, some background; I had already planned on working Thursday and Friday this week (for those of you not in the US, Thursday is a national holiday). I’m trading time off now for use next month when I’ll be in Michigan. It’s nice to have a manager who is flexible like that.
During today’s platform meeting, a great debate started about when we should branch for Firefox.Next. We had originally planned on branching roughly three weeks ago, but we are a bit behind schedule. It turns out this hurts our mobile efforts since the tree is essentially under lock-down, and has been since when we intended to branch. Folks on the call were arguing when would be a good time to branch, with suggestions ranging from now, to (I believe sarcastically) a month or two from now. Branching now means a lot of people have to land patches to bugs to both branches, and branching later means life is painful for mobile for even longer. It was clear to me that we weren’t getting anywhere with the argument and people were just digging into their positions, which is when I decided to do something a bit crazy. This quote from the backchannel chat sums it up nicely (thanks to whoever submitted it as I now have a record of my insanity). Essentially, I’m landing a bunch of patches to make a lot of other folks’ lives easier over the next few weeks or so. Here’s hoping I don’t keep taking steps to further my madness!
This does mean that I’ll be around online Thursday and Friday this week if you need to get a hold of me.