This is where to find what you need to know in order to check code in to mozilla's CVS repository. If you've never built mozilla before, then you should start by looking at the source code and building it.

If you have a patch to fix a bug, submit it to Bugzilla as an attachment to that bug. Use the mozilla.patches newsgroup to discuss patches. When you're submitting patches frequently and have an established track record of good XP code then we may want to give you your own checkin priviledges.

To get write access to the CVS tree, someone must vouch for you. Usually this will be a module owner. The person who vouches for you will be responsible for making sure you know and follow our rules and will be responsible for your tree breakages if you're not around to fix your own. Vouching for another person is a big responsibility so owners need to take care who they vouch for. They will want to see evidence that you do good work that rarely busts the tree. Usually they will want to see a record of patch submissions although they may skip this formality for co-workers whose work they're already familiar with.

Before we create your account, you'll need to fill out the CVS Contributor Form. Signing the form indicates you understand and agree to our legal requirements. Breaking these rules could cause legal problems for mozilla.org and may force us to revoke your CVS access. If you have any questions, ask us.

It's illegal for us to distribute crypto so don't check in crypto or a crypto API.
All source files must contain a license header using the NPL or MPL and you must provide the legal notices required by the license, if any.
The code you check in must belong to you or you must have full rights to publish and license it.
Your CVS account is for your own use only. Do not let others use it. If you check in someone else's patch, attribute the patch to them in the CVS log.

Our next 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. We inherited a build process that's been in place at Netscape since Communicator 4.0. It's 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.

Other guidelines:

One of our primary design considerations is that our code work on a wide variety of platforms. There are people porting mozilla to small platforms using compilers that may not support all the latest standards. 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 marginal platform like your cable box or cell phone.
Read our development roadmap. This is the architectural overview of where the mozilla browser is heading, and good reading for anyone hacking mozilla.
Learn to use bonsai effectively. Bonsai 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 source file, put your name in the "Created By" section. If appropriate, add yourself to the contributors section of the license header of files you modify.

Happy hacking!