|
|
| (5 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.
| |
| *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.
| |
| | |
| == Please do the following after landing on mozilla-inbound ==
| |
| | |
| In order to save time for the people doing the merges, after pushing to inbound please:
| |
| *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).
| |
| *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.
| |
| *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.
| |
| Thanks :-)
| |
| | |
| == 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)
| |