Firefox/Projects/TabCandy/Work: Difference between revisions

Jump to navigation Jump to search
No edit summary
Line 83: Line 83:
# Create a bug in bugzilla describing what your patch will do/fix, or use an existing bug if appropriate
# Create a bug in bugzilla describing what your patch will do/fix, or use an existing bug if appropriate
# If the patch fixes a bug or adds a feature (rather than, say, code clean-up, string changes, style changes, etc), it should have a unit test.   
# If the patch fixes a bug or adds a feature (rather than, say, code clean-up, string changes, style changes, etc), it should have a unit test.   
# Try the tests locally: '''TEST_PATH=browser/base/content/test make -C ''<objdir>'' mochitest-browser-chrome'''
# Regardless of whether you're adding a test, try all the browser chrome tests locally: '''make -C ''<objdir>'' mochitest-browser-chrome'''
# Attach your patch to the bug and assign it for feedback from one of the Panorama team
# Once you've got f+, mark it r? for review (ask in #tabcandy if you're not sure who to assign it to)
# Once they've given you an r+, you'll need approval (unless it's already marked as a blocker, which means it's already approved for landing):
## Mark it with a question mark under "approval 2.0", if the reviewer hasn't already done so
## If it's a rush, poke someone to do the approval 2.0 (again, ask in #tabcandy if unsure who)
# Push your patch to tryserver to make sure it doesn't break anything:  
# Push your patch to tryserver to make sure it doesn't break anything:  
## Update your m-c local repo  
## Update your m-c local repo  
Line 89: Line 94:
## hg push -f ssh://hg.mozilla.org/try
## hg push -f ssh://hg.mozilla.org/try
## Check the results at: http://tests.themasta.com/tinderboxpushlog/?tree=MozillaTry
## Check the results at: http://tests.themasta.com/tinderboxpushlog/?tree=MozillaTry
# Attach your patch to the bug and assign it for review (ask in #tabcandy if you're not sure who to assign it to)
# Once you've got your approval, make a fresh patch with the commit message giving the bug number and title (if you haven't already done that), and updated with [r=foo a=bar]
# Once they've given you an r+, you'll need approval (unless it's already marked as a blocker, which means it's already approved for landing):
## Mark it with a question mark under "approval 2.0", if the reviewer hasn't already done so
## If it's a rush, poke someone to do the approval 2.0 (again, ask in #tabcandy if unsure who)
# Once you've got your approval, make a fresh patch with the commit message updated with [r=foo a=bar]
# Mark the bug for checkin, by adding the keyword "checkin-needed" to it.
# Mark the bug for checkin, by adding the keyword "checkin-needed" to it.
# Add it as a "ride-along" on the landing queue: https://wiki.mozilla.org/LandingQueue  
# Add it as a "ride-along" on the landing queue: https://wiki.mozilla.org/LandingQueue  
68

edits

Navigation menu