DevTools/ReviewTips
< DevTools
General
During Development
- Ask for feedback early. You can ask anyone for feedback, but asking a reviewer might speed up the process of getting review later
- Don't leave it until the last moment to write tests
- cedricv has some awesome code coverage tooling to make your tests better
Mercurial
- Mercurial branches are a bit heavyweight for our development needs. MQ helps
- Your ~/.hgrc should include:
[defaults] diff = -U 8 -p qdiff = -U 8 qnew = -U [diff] git = 1 showfunc = 1 nodates = 1 [extensions] fetch = hgext.graphlog = hgext.mq = color = rebase =
- Other nice things for your ~/.hgrc:
[defaults] commit = --verbose blame = --user --date --quiet --number --line-number qseries = --summary [alias] qlog = log --stat -r qtip:qbase # http://mercurial.selenic.com/wiki/ColorExtension [color] qseries.applied = green qseries.unapplied = yellow qseries.missing = red
Getting Review
- Ask for review when you believe that it's ready to land, which means:
- Tests (which pass)
- A patch that cleanly applies to fx-team
- A patch with a message in the format 'Bug XXXXXX - Message' (pro-tip: cut and paste from the Bug page)
Other sources of hints and tips:
Headers
- Make sure each file starts with the standard copyright header (see License Boilerplate)
- For work funded by Mozilla, the 'Initial Developer of the Original Code' should be 'The Mozilla Foundation'.
- Remember the year
- The first letter of contributors names should be under the 'n' of 'contributors'
- The original author of the code should have the string ' (original author)' after his/her email address
CSS
- See DevTools/CSSTips
Reviewers:
- dao
JavaScript
See:
Reviewers:
- dcamp
- msucan
- robcee
Localization (l10n) / DTDs and Properties
General
- Moving files is annoying because localizers are language experts but not HG experts and they work off a different repo with a similar structure, so they have to mirror your file movements
Reviewers:
- dcamp
- msucan
- robcee