Tree Rules/Integration: Difference between revisions

Line 31: Line 31:


= Sheriff Duty =
= Sheriff Duty =
* Sheriffs will watch this tree and back out bustage/regressions as necessary to keep it green.
* Sheriffs will watch these trees (mozilla-inbound and autoland) and back out bustage/regressions as necessary to keep it 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".  
** The backout will be noted in the bug. The onus isn't on the sheriff to contact the developer via IRC regarding the backout. Developers who do not read all bugmail are encouraged to set up appropriate mail filters on bugs to which they are assigned, to ensure they are aware of the backout.
** The backout will be noted in the bug. The onus isn't on the sheriff to contact the developer via IRC regarding the backout. Developers who do not read all bugmail are encouraged to set up appropriate mail filters on bugs to which they are assigned, to ensure they are aware of the backout.
** If it's not possible to identify the guilty changeset, the sheriffs may backout more changesets to minimize the overhead/time to fix the tree. Completely innocent pushes will be relanded by the sheriff once the bustage is cleared or, in case of doubts, a Try server run will be requested in the bug, before the next landing.
** If it's not possible to identify the guilty changeset, the sheriffs may backout more changesets to minimize the overhead/time to fix the tree. Completely innocent pushes may be re-landed by the sheriff once the bustage is cleared or, in case of doubts, a Try server run will be requested in the bug, before the next landing.
** 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], or mak's [https://wiki.mozilla.org/User:Mak77 backout shell script] or Sfink's [https://bitbucket.org/sfink/qbackout qbackout Hg extension].
* About once a day or more, merge a green integration repository push with valid PGO results to mozilla-central.
* About once a day or more, merge a green integration repository push with valid PGO results to mozilla-central.
** If the push includes compiled files or changes to configure/Makefiles it must have green PGO builds. Otherwise, the first push before it including such changes must have them.
** If the push includes compiled files or changes to configure/Makefiles it must have green PGO builds. Otherwise, the first push before it including such changes must have them.
** Also merge mozilla-central to each integration repository. Merge any large or disruptive changes from central sooner.
** Also merge mozilla-central to each integration repository. Merge any large or disruptive changes from mozilla-central sooner.
** Resolve bugs that were landed, and set the appropriate target milestone.  The [http://www.graememcc.co.uk/m-cmerge/ m-cMerge tool] partially automates this step.
** Resolve bugs that were landed, and set the appropriate target milestone.  The [http://www.graememcc.co.uk/m-cmerge/ m-cMerge tool] partially automates this step.
** When merging inaccessible security fixes, send email to the bug assignee and Cc the reviewer, to politely ask them to resolve their bug.
** When merging inaccessible security fixes, send email to the bug assignee and Cc the reviewer, to politely ask them to resolve their bug.
canmove, Confirmed users
2,850

edits