Inbound Sheriff Duty: Difference between revisions
Jump to navigation
Jump to search
m (Requesting that try links (if there are any) are added when pushing to m-i) |
(→What are the tree rules for mozilla-inbound?: Clarification around extra info needed if multiple patches + emphasise no longer using [inbound] in whiteboard) |
||
| Line 18: | Line 18: | ||
*Bugs remain open until the changeset makes it to m-c. | *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: | *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. | **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. | **Set the target milestone. | ||
**Check the assignee, platform, in-testsuite flag & other fields are correctly set. | **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. | **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> | **<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 | *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". | **Bustage is backed out right away. There's no "we'll let you fix this tree while everybody stands by". | ||
Revision as of 11:33, 20 September 2011
Where is mozilla-inbound?
http://hg.mozilla.org/integration/mozilla-inbound
To speedup the cloning you can use the mercurial bundle:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/bundles/mozilla-inbound.hg
or see 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.
Optionally add "[inbound]" to the status whiteboard for bugs that have been fixed on mozilla-inbound.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 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)