- Your code must compile and pass all the automated tests before you consider pushing changes. If you are at all unsure, verify your changes with the mozilla-central or comm-central try server, as appropriate.
- You need code review. Depending on the patch, you may also need super-review. Depending on the stage of the development process, you may need approval.
- If your code is likely to break a product other than the one you are focused on (e.g. SeaMonkey or Camino), it's polite to warn them in advance. For instance, you might send a message to mozilla.dev.apps.seamonkey.
The checkin comment for the change you push should include the bug number, the names of the reviewers and a clear explanation of the fix. Please say what changes are made, not what problem was fixed, e.g.:
Good: "Bug 123456: Null-check pres shell so we don't crash when a button removes itself during its own onclick handler. Patch by email@example.com; r=paul; sr=george; a=ringo."
Bad: "Bug 123456: crash clicking button on www.example.com"
Bad: "Fix bustage. Oops!"
There may be additional information required for checkins which represent merges from a different tree. (XXXdtownsend?)
If you are not the author of the code, use
hg commit -u to specify the actual author in the Mercurial changeset:
hg commit -u "Pat Chauthor <firstname.lastname@example.org>"
Tinderbox is a continuous build system. The appropriate tinderbox gives the current state of a particular tree. The tinderboxpushlog combines tinderbox information with the list of commits. For a particular build, green means all is well, orange means tests have failed, and red means the build itself broke.
If the tinderbox is green, it is okay to check in. If some builds are orange or red, you can either wait, or make sure all the failures are "starred" with comments that reference bug numbers or fixes.
If the tree is marked as "closed", or if you have questions about any oranges or reds, you should contact the sheriff before checking in.
Watch The Tree
Once you have checked in, you need to watch the tree and make sure the next cycle for every machine is green. A good rule of thumb is that it will take 1.5 hours to make sure your change compiles correctly on all platforms, 2.5 hours to make sure the unit tests pass, and 4 hours to make sure the "Talos" performance tests don't regress and don't crash on your changes. Therefore it is unwise to check in if you won't be available for the next 4 hours.
If the tinderbox goes orange or red, you are responsible for figuring out whether you broke it and communicating with the sheriff on IRC. Sometimes tests randomly fail; to see if your failure is one of those, search the randomorange bug dependency list for the name of the failing test. Otherwise, patches which break the tree or cause unit test or performance regressions should be backed out.
The following documents seem to contain some of this information; I am hoping we can consolidate.