Darrell Norton's Blog [MVP]

Sponsors

The Lounge

News

  • Darrell Norton pic

    MVP logo

    View Darrell Norton's profile on LinkedIn

    Currently Reading:

    weewar.com

Advertisement

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
The Mozilla Development Process

A lot has been made about how great the Firefox browser is, and how it’s finally better than IE. One thing that has been overlooked, though, is the process Mozilla is using to develop software. Sure, everyone laughed when Joel Spolsky called the decision to rewrite the code base from scratch stupid, but nobody has picked up on how well they are doing now. Firefox is currently available in 24 languages with 7 more on the way on 10 different operating systems (flavors of Windows, Mac, and Linux) and is setup to work on 32 and 64-bit systems.

The secret is right on Mozilla’s web site, in the Hacking Mozilla site and in the Introduction To Hacking Mozilla. There are strict guidelines on writing portable C++ to keep Mozilla compiling on all those different platforms. There is a coding style guide that is enforced by code reviews. And the Mozilla roadmap paints a clear direction for the future of the project, as well as discussing how past events have led to current decisions (gee, I wish I had that on all my projects!).

All code is reviewed before being committed to source code control, usually twice. First, the module owner has to approve the code, or else the code doesn’t get in. There are very clear rules about check-ins and there is a checklist for code reviews. The existence of module owners and peers, people to whom the module owner has delegated authority to, also implies that there is clear ownership of code through the modules. Then most code is reviewed again by a “super-reviewer.” The neat thing about a super-reviewer is that they earned their reputation by continually making good decisions on whether code is good or bad based on the track record of check-ins.

Then comes quality assurance. There is a pre-check-in test list, full smoke tests including performance testing, and detailed accounting that makes everyone who checks in code “on the hook.” Being on the hook means that you are around to make fixes should the build break. Chris Yeh writes,

“After checking-in, you watch Tinderbox until your check-ins clear. You do not go home. You do not sleep. You do not log out or experiment with drugs. You do not become unavailable.”

Builds are watched over by a different sheriff every day. The sheriff watches over the builds, opens or closes the tree for various reasons, fixes blockers, and hunts down whoever broke a build to get it fixed as quickly as possible.


Posted 11-24-2004 12:03 PM by Darrell Norton

[Advertisement]

Comments

Robert O'Callahan wrote re: The Mozilla Development Process
on 11-25-2004 2:34 AM
Don't believe everything you read. Those documents are still basically accurate but there have been some changes.

There is no designated sheriff anymore. Tree closure and repair are managed by whoever's on #developers in the Mozilla IRC network. Hardly anyone ever runs the pre-checkin tests. The smoketests are not run regularly anymore.

In many cases review and super-review are granted by the same person simultaneously. Sometimes there aren't the resources to do a proper review; if the code author is sufficiently trusted, they may get a "rubber stamp" review. In some modules and at some times, review requirements are waived completely. In any case, the quality of reviews varies a lot. Code ownership isn't nearly as strong as we would like.

Many of these changes have come about because we've been tuning the process over the years, especially by relaxing requirements that we perceive to be more onerous than their benefit warrants. Some changes have also come about because of the changing personnel and direction of the project.
Robert O'Callahan wrote re: The Mozilla Development Process
on 11-25-2004 2:37 AM
Also, be aware that this process depends on the fact that thousands of people download and use our nightly builds --- that's how we get away without formal smoketesting. It is not suitable for every project.
Jay Nathan wrote re: The Mozilla Development Process
on 11-25-2004 4:30 AM
In my experience, it has been limited timelines and budgets that prevent this level of detail from being attained on projects.
Paul wrote re: The Mozilla Development Process
on 11-26-2004 12:32 AM
I still feel the point Joel made is valid. Firefox is only competitive now because of IE's four year stagnation. Its taken those four years to get to the same feature level as IE, plus tabs! Don't get me wrong - I love FF and its my main browser but I wonder where it would be now if it wasn't redeveloped from scratch. Perhaps we'd all be running lovely XUL/XAML interfaces now rather than trying to fix sites that don't run FF and IE HTML crossbrowser.
Darrell wrote re: The Mozilla Development Process
on 11-26-2004 5:34 AM
Robert - thanks for the update! It's true that thousands of developers help reduce the need for smoke testing, and that downloading a nightly build has a lower expected level of quality. I just don't know how I could get away with it on a corporate project. :)
Darrell wrote re: The Mozilla Development Process
on 11-26-2004 5:34 AM
Paul - I agree it was a mistake then, I was just mentioning that now nobody gives credit where credit is due (even though they might not need all the credit I gave them, after Robert's comments!).
ThoughtChain wrote Software Developement Process
on 01-06-2005 9:36 AM