Mozilla.org

General Notes

This document covers all patches to the mozilla/browser hierarchy. For questions or concerns arising from this document, please direct questions to the dev-planning mailing list/newsgroup.

Review Rules

• Wherever possible, patches should be reviewed by the sub-module owner or additional reviewers. The reviewers are listed in preferred order, please try to follow that order.
• Peers may grant review in any area, provided they feel confident in their knowledge of the code being changed.
• One review is sufficient in most cases. If the first reviewer feels that the patch would benefit from additional reviews, they should request a second review from an appropriate person.
• Super-review is now required where required by the mozilla.org super-review policy.
• Members may only grant review in areas they are listed as reviewers.
• User interface & experience changes must have ui-review from someone in the UI group, along with code review.

Unit-Test Rules

• All patches must include unit tests which are run during make check. Once unit tests are committed, the in-testsuite+ flag should be set on the bug.
• Unit tests must be included in patches and reviewed just like any other code.
• If running the test during make check is not possible, consult with Robert Sayre (sayrer) to determine whether another test system is available.
• If a unit test framework is needed but is not yet available, the developer should write appropriate test code and commit it. A bug should be filed on the needed test framework. The in-testsuite? flag should be set on the bug until the framework has been completed and the test code is running automatically.
• Certain build-config or tooling bugs which don't affect the actual product cannot be usefully tested. Additionally, there are many trivial and obvious fixes (typos, theme CSS changes, etc) that fall into this category. These bugs should have the in-testsuite- flag set.

Individuals and Roles

Sub-Modules