Mozilla Code Development Cycle

To be a successful Mozilla programmer, you have to be a team player. That includes following the established rules, even if you don't agree with them.

The Mozilla code development cycle is, generally, rather simple. Overall, there are only a few steps:

1.	Find a bug you want to fix and that you think you can fix. As a suggestion, fix the bug unofficially before asking for the formal approval to work on the bug.
2.	Make your fix to the relevant module. Test your fixes do not just assume that they will work. If at all possible, test it under all platforms, including Windows, Mac, and Linux.
3.	Create a patch file using the DIFF command (part of Cygwin).
4.	Find the bug and ensure that it is currently unassigned (see Figure 18.1). Figure 18.1. This bug is new and is currently unassigned.
5.	Request the bug be assigned to you. This is done at the bottom of the Bugzilla bug form, as shown in Figure 18.2. Figure 18.2. A bug's status and resolution can be altered if you have the authority to do so.
6.	Fix the bug. Generate a patch file, and attach the patch file to the bug in Bugzilla. Request a review for the attachment's patch.

The review process is necessary before your bug will be added to the product. The reviewer (usually the module owner or his peer) checks to ensure that the fix is acceptable and tests the fix. Do not take this as saying that Mozilla doesn't trust you this benefits you in that there is an extra set of eyes looking for unintended side effects.

Without careful review, there is a tendency for a bug fix to simply cause another bug in the program. Always be careful not to break something else when fixing your bug.