Author: Shawn Wilsher

I meant to get to this yesterday, but yesterday turned out to be a busy day. I meant to get to this earlier today, but today turned out to be a busy day too…

As I previously announced, I’m going to try an experiment with sheriffing the tree. While I’m the acting sheriff tomorrow (that will be from 9am – 6pm EDT), you’ll have to run checkins through me. To make this easy as possible, there are going to be a number of ways in which you can get a patch to me (in the preferred order):

• Send me an e-mail with your hg bundle that includes the correct commit message.
• Attach your hg bundle to the bug you want pushed, and add that bug to the wiki page.
• Just post a bug number on the wiki page with the appropriate checkin comment.

I’ll also be going through checkin-needed bugs when things are slow. The general rule here though is that it’s a first-come, first-serve push ordering. I might take things out of order if the queue is big and I see bugs/patches that won’t interfere with each other.

Hopefully that clears up any confusion about tomorrow. I apologize for not getting this out sooner, but today was crazy. :)

I’m up for sheriff duty this Thursday, and I thought I might try something that people have discussed many times. It’s a bit radical, and I’m not sure if people will like it though. The idea is to only have the sheriff push changesets. This way, the sheriff can push things at a rate he/she is comfortable with, and stay on top of all the performance charts and random oranges. If it happens to be a slow day, I’ll be going through the checkin-needed bugs and pushing those as well.

It makes sheriffing a full time job, but I think it’s worth a try to see how it works out. I also think it will be a valuable data point to determine if we want to do it like this all the time.

Feedback wanted (posting to dev.planning as well)!

I’ve seen several comments all over the place asking why we couldn’t, in Firefox 3, provide an option for users to revert back to the old UI for many things; or, my personal favorite, default to the old UI and make the new UI optional. Today, my goal is to explain why we don’t do this.

I’ll start with the second one since I enjoy it so much. The thing with new software is that users expect something new. If you default to the old UI, your user base is going to wonder what exactly you did in this new release, and why they even bothered upgrading. This only applies to major updates though, as people generally don’t expect anything new out of security updates. This user expectation is why we’ve had some form of visual refresh in almost every major update (at least as long as I’ve been following the project).

Now, why don’t we provide a way to get back to the old UI via a preference (even if it is just a hidden one)? There are actually a number of reasons why this is a bad idea:

• Performance
• Code bloat
• Test coverage
• Feature bloat

Each time you add a preference, you make that code run a bit slower. In many cases the overhead of dealing with preferences can be dealt with more code, but then you end up with a new problem – code bloat.

Code bloat may seem insignificant to an end user, and it probably doesn’t matter too much to them. That is, until you factor in the fact that more code means more that the developers have to worry about. All that extra code means bugs are more likely to be introduced, and new features take longer to add. Extensive test coverage can help prevent the bugs from creeping in, but it won’t help with new features being developed.

Test coverage doesn’t seem like a big deal when it comes to optional features. “Big deal – you just have to have a few more tests for those options,” right? No, not really. In reality, the code better have every combination of options tested to make sure they work well together, otherwise the bug reports and complaints will come flying in. Now, my probability and statistics is a bit fuzzy, so I hope I’m getting this math right. Let’s say you have just four features, each with only two options. There are 2⁴ possible combinations, or 16 possible combinations that you have to test for. You can see how quickly this will blow up once you start adding more features to test for, as well as more options per feature. It gets pretty ridiculous pretty fast.

I leave feature bloat for last because there are people out there that will disagree with me on this being a bad thing. Giving users lots and lots of choices can quickly result in confusion. Having confused users is a bad thing, because it will end up driving them away from your product. As a result, we try to keep things simple, but at the same time make them useful for the majority of people.

All is not lost, however! The beauty of Firefox (and the Mozilla platform in general) is the extensibility of it. Say you don’t like the new download manager UI – it’s pretty easy to create an add-on that uses a totally different UI. I made sure of this when we were doing these changes. It may not be as easy elsewhere in the application, but there is almost always a way to customize it with an add-on. This is what has made Firefox so successful – if you don’t like something that most people are OK with, you can change it. Keep in mind, there are many core features that were first developed as add-ons (like session restore, the new theme for OS X, the download information in the statusbar).