Hacking Mozilla
This is where to find what you need to know in order to get your code checked in to mozilla's CVS repository. If you've never built Mozilla before, then you should start by downloading and looking at and building the source code. Then check out the Mozilla Hacker's Getting Started Guide.
Life Cycle of a Patch
If you are looking to create a patch, the following guidelines may be useful:
- One of our primary design considerations is that our code work on a wide variety of platforms. There are people porting Mozilla to embedded platforms using compilers that may not support all the latest standards. If you are writing compiled code (C, C++), help these platforms by following our C/C++ Portability Guidelines and compiling with as many warnings turned on as possible. Maybe one day you'll find your code running on a truly unusual platform like your cable box or cell phone.
- Make sure that your code is localizable. There are 62 registered localization projects, of which seven to ten are currently active.
- Be aware of the Mozilla Style Guidelines.
- Take customizability into account. One of the biggest advantages of Mozilla technology is customizability. Vendors or distributors of Mozilla might have special requirements of tailoring Mozilla towards their needs. To facilitate the distribution of Mozilla, please take customizability into account so optional features can be added, removed, modified easily.
- Read our development roadmap. This is the architectural overview of where the Mozilla browser is heading, and good reading for anyone hacking Mozilla.
- When creating a new source file, add boilerplate license headers as appropriate, and fill in the blank fields. If appropriate, add yourself to the contributors section of the license header of files you modify.
- Patches should be created against current CVS, preferably with enough context to be understood without opening the source file. A good default guideline is to use cvs diff -u8pN at a minimum. If more context is required to make the patch understandable, replace 8 with a higher number.
When you have a patch, submit it to Bugzilla as an attachment to that bug. We're big believers in code review, so before code is checked in to the CVS Repository it must be reviewed by the appropriate module owner or one of his peers. Modules do not quite directly correspond to Bugzilla Components, but there is a strong correlation. To get review:
- Ask a module owner or peer for the module in question
explicitly for a review by setting the review flag for the patch to
?(indicating that review is requested) and entering the email address of the person from whom you are requesting review. - You may also mail the module owner or peer directly, mentioning the bug number, the fact that you have a patch attached, and that you would like them to review it. However, requests made using Bugzilla's request feature are less likely to get lost.
In some cases, you will receive a response within the next few days. Unfortunately, some people are too busy to catch up with all their bug news. So, if you don't receive a response within a week, and you think the patch deserves attention now (instead of, say, in a year or so), you could:
- Ask Bugzilla who else has reviewed patches for bugs in that component, and ask them to review it instead
- Ask on IRC in #developers as to who a suitable reviewer might be. Note: request review via email, not on IRC
The reviewer may well have comments on your patch which you will need to address. When they are satisfied, they will mark the patch as reviewed, and maybe say "r=<user>" in the bug.
In most cases an additional level of review known as "super-review" is required. The super-review document details how to go about getting super-review. Again, the super-reviewer may request changes to your patch, and when they are happy, they will say so in the bug.
When you have review and super-review, and your patch is as good as it can
be, it can be checked into the tree. If you do not have a CVS account, you
will need to find someone to check it in for you, which is actually really
easy: just add the checkin-needed keyword to the bug. A handful
of committers have searches set up for this and occasionally go through and
commit uncommitted patches, usually within a week or two of your adding the
keyword. If it takes longer than two weeks, it's probably worth jumping on IRC
and asking for someone to commit your patch (and go through the bugs with
checkin-needed, too, since many of them will have been waiting just
as long).
Occasionally, the tree is locked down a little tighter approaching a release,
and a third level, called "approval", is required before you can check in.
During these times, Tinderbox
will have a notice at the top saying that approval is required. To request
approval, set the appropriate approval flag to ? by editing
the attachment.
If approval is refused, you may have to wait a week to check in your patch,
until the release is made or development for the release moves onto a
branch.
If you are having any trouble with this process, or need guidance, please mail Gerv.
CVS Commit Access Rules
When you've been contributing patches frequently and have an established track record for good quality code, you can start the process of getting CVS Commit access. The following rules apply to those with CVS Commit access:
The most important rules are those regarding the build process. Disregarding them wastes a lot of other people's time. Blatant offenders will be pestered into compliance. Resistance is futile.
- Learn to follow the tree rules. Our build process is flexible, works with a minimum of human intervention and has scaled to work with hundreds of engineers. This process works and will continue to work if people follow these simple rules.
- Everyone checking into the repository must do their part to keep the tree green. Make sure your code builds on other platforms before it's checked in. After your checkin, it's your responsibility to make sure tinderbox builds your code sucessfully, and to be available to help fix unanticipated build or runtime problems. Breaking the tree wastes time for many people. Don't do it.
- Learn to use Tinderbox effectively. Tinderbox can be used to find all sorts of information about the tree. As someone checking in code to the tree, you must use bonsai to find out news about the tree, such as whether it's open and whether there are any planned closures.
- When creating a new directory, get the permission from the owner of the containing directory. To add a new directory to to the "mozilla" top-level directory, contact the mozilla.org staff. We prefer not to add new top level directories unless there is a very good reason. Most new projects will fit somewhere already in the tree, like components.
Happy hacking!