Hacking Mozilla Table of Contents
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.
Run Smoketests using Litmus
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.