- 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.
With Mercurial, checking in is a separate stage to pushing to the shared repository. 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. The tree can also be marked as Open or Closed, although some checkins may be permitted to a Closed tree (those who need to do it will be told how). If the tinderbox is green and the tree is open, you may check in without any further confirmation. If the tree is orange or red or closed (and you don't meet the conditions), you can either wait, or talk to the sheriff (the person managing the tree that particular day) to find out what's going on.
The text at the top of the tinderbox will tell you:
- how to contact the sheriff;
- any tree-specific checkin rules (which are hereby incorporated by reference into these rules). Commonly-referenced rules are those for:
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.