Inbound Sheriff Duty: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(→‎What are the tree rules for mozilla-inbound?: Clarification around extra info needed if multiple patches + emphasise no longer using [inbound] in whiteboard)
(redirect to Tree Rules/Inbound)
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Where is mozilla-inbound?  ==
#redirect [[Tree Rules/Inbound]]
 
http://hg.mozilla.org/integration/mozilla-inbound
 
To speedup the cloning you can use the [https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29#Bundles mercurial bundle]:
 
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/bundles/mozilla-inbound.hg
 
or see [http://jlebar.com/2011/5/20/Faster_and_smaller_clones_of_branches.html this blog post].
 
== What are the tree rules for mozilla-inbound?  ==
 
*'''mozilla-inbound is no replacement for Try'''
**Please avoid any unnecessary breakage. You still need to test your patches on [[Try]] before pushing.
*'''When can I push to mozilla-inbound? Always!'''
**If there is something very wrong with mozilla-inbound, a sheriff will close the tree, and your push will fail automatically.
*Committers are ''not'' required to actively watch the tree after pushing to mozilla-inbound.
*Bugs remain open until the changeset makes it to m-c.
*When landing on inbound, please make the following bug state changes, to save time for the people doing the merges:
**Add the inbound changeset URL to the bug. NB: If there are multiple patches on the bug, please indicate which one the changeset is for (eg: use patch -> details -> comment on patch).
**If the bug should remain open after the inbound changeset makes it to mozilla-central (eg patches left to land or other work needs doing), please indicate this in the whiteboard.
**Set the target milestone.
**Check the assignee, platform, in-testsuite flag & other fields are correctly set.
**If this has been sent to try, please include the URL, so in the case of mozilla-inbound bustage, it's easier to eliminate your push as the cause.
**<strike>Optionally add "[inbound]" to the status whiteboard for bugs that have been fixed on mozilla-inbound.</strike> '''Please do not do this any more''', as it means the merges take even longer - and was not being done consistently anyway, so better to just use the inbound changeset URL comment as indication of landing on inbound instead.
*The Sheriff will watch this tree and back out bustage/regressions as necessary to keep mozilla-inbound green
**Bustage is backed out right away. There's no "we'll let you fix this tree while everybody stands by".
**Changes landed on top of bustage will be backed out to minimize overhead/time to fix the tree. They will be relanded by the sheriff once the bustage is cleared.
**See ehsan's blogpost on how to [http://ehsanakhgari.org/blog/2010-09-09/backing-out-multiple-consecutive-changesets-mercurial back out multiple consecutive changesets]
*Once or more a day, the sheriff will merge a green -inbound changeset to -central
**Resolve bugs that were landed, set appropriate target milestone.
*Push to mozilla-inbound like any special branch, that is, it is recommended to have a separate local tree. Pull to it, apply your patches, and then push to mozilla-inbound.
 
== Who manages mozilla-inbound?  ==
 
*bz (EDT/UTC-0400)
*ehsan (EST) (not a morning person, so might be kind of similar to PDT!)
*khuey (EDT)
*mak (CEST/UTC+0200)
*mbrubeck (PDT/UTC-0700)
*volkmar (Late European TZ)
*philikon (CEST/UTC+0200)
*rnewman (irregular hours for personal reasons; PDT)

Latest revision as of 05:35, 7 October 2011

Redirect to:

Retrieved from "https://wiki.mozilla.org/index.php?title=Inbound_Sheriff_Duty&oldid=356035"