Hacking Mozilla Table of Contents[z]

To get your code checked into mozilla.org's CVS repository you'll need to understand our code development cycle, coding practices, and checkin requirements. You probably also want to have a reasonable understanding about the project's organization.

(If you're looking for the document called Hacking Mozilla that used to live at this page, go to the first link below.)

A. Code Development

Life Cycle of a Patch (formerly "Hacking Mozilla")
An overview of how to get the source, develop patches, get them reviewed, super-reviewed and checked in the tree.

Mozilla Hacker's Getting Started Guide
How is the source code organized, where to start, critical tools, rules to follow to contribute.

Good First Bugs
Want to help, but don't know where to start? Here are a few suggestions.

Code review
An FAQ about mozilla.org's code review and super-review process - what it's for, how it works, what to expect.

Super-review
What code needs super-review, what to do if you're seeking a super-review, a list of super-reviewers, plus some tips about what to consider in your code before seeking super-review.

Development Strategies
Some strategies to help developers stay productive.

Tips on Contributing New Features to Mozilla
Design and implementation suggestions for large contributions.

B. Mozilla Coding practices

Mozilla Coding Style Guide
Explanation of the basic styles and patterns that are used in the Mozilla codebase. New code should try to conform to these standards.

Seamonkey Code Reviewer's Guide
A high level outline of what to look for when doing a code review.

Rules and Tips
Questions to ask about your code before you submit it for super-review.

C++ portability guide
Rules, guidelines, and tips for making C++ code portable across many machines and compilers.

C. Checking Code into the mozilla.org tree

Working with the Seamonkey Tree
Description of how to build and test your code before checkin, how mozilla.org manages checkins and each developer's responsibilities to the community when code is committed.

The Seamonkey Engineering Bible
An older but still useful document containing guidance on how to make checkins go smoothly.

Pre-checkin tests
The minimum tests that must be run before you check code in.

Hacking Mozilla with Bonsai (aka "Being on the Hook")
When your code is checked in you are "on the hook." Here's a description of what this means..

Tinderbox Performance tests
These are the tests Tinderbox runs to measure performance. They can be run on patches whose performance impact is suspect.

Performance Regression Policy
When the tree is to be closed due to performance regressions and how it is to be reopened.

Full Smoketests
Tests Mozilla Community QA runs each day on the verification builds.

Getting commit access to Mozilla source code
Steps required to obtain CVS write access to mozilla.org's CVS repository.

Using SSH to connect to cvs.mozilla.org FAQ
A guide to setting up access to cvs.mozilla.org using ssh.

How to complete the CVS Contributor Form
Information on completing the form one needs to fill out as part of the process of getting CVS write access, plus a link to the form itself.

D. Project Organization

Mozilla Roles and Responsibilities
A description of the formalized roles in the Mozilla community -- mozilla.org, drivers, module owners, etc.

Mozilla Modules and Module Ownership
Information on the nature of Mozilla modules, role of module owners, criteria for module ownership, and designating module owners.

Handling Mozilla Security Bugs
mozilla.org policy for handling bugs related to security issues.