Code Review
Before you can check in a patch to Firefox, you must have your code
reviewed. This is done by soliciting review for your patch in the bugzilla
bug where you are conducting your work.
Area of Code
This policy covers the mozilla/browser directory structure.
Requirements
- One level of review is required. For codebase-wide
simple, repetitive changes (such as relicensing, spelling, whitespace
or capitalization changes), review from a Firefox Peer is not
required as long as the patch as a whole has review.
- Please test your changes thoroughly in Firefox before soliciting review.
Firefox contains many subtle differences from Seamonkey and we get
annoyed when these things break because they're hard to spot. Where
possible, write unit tests or test cases before you write code.
- Significant UI changes (e.g. changing the behaviour of a dialog, pref
changes, visual modifications beyond alignment/appearance inconsistencies)
should be reviewed by the Firefox owner or a peer.
- When making significant changes or additions, please ensure that all
relevant source comments/documentation are accurate and up to date.
If there are none, please consider filling in the gaps to save others
time in the future.
- While we will do our best to get things together so they can land before
freeze, giving us a reasonable amount of time is paramount to us actually
following through on this.
- Make it clear what you're doing to the reviewer. Avoid just dumping a
large patch in a bug and soliciting review. Refer to a design doc for
your change or describe the gist of your changes in the bug. This will
make the reviewer more likely to review your code faster, understand
it better and provide more thoughtful commentary.
Some Tips for Writing Good Code
How to Solicit Review
In bugzilla, attach your patch and set the "review" flag dropdown to "?"
and enter the email address of one of the Firefox reviewers listed below.
Current Reviewers