Tree Rules/Integration - Revision history

Archaeopteryx: /* Sheriff Duty */ quick follow-up fixes might be accepted to prevent overhead of backout and reland

2024-05-28T09:16:42Z

Sheriff Duty: quick follow-up fixes might be accepted to prevent overhead of backout and reland

← Older revision		Revision as of 09:16, 28 May 2024
Line 32:		Line 32:
	= Sheriff Duty =		= Sheriff Duty =
	* Sheriffs will watch these trees (mozilla-inbound and autoland) 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~~."		** If code sheriffs notice a permanent task failure, they might reach out to the developer to check if the issue is simple mistake which can be fixed with a follow-up patch provided to them through Phabricator in the next 5 minutes.
	** 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 back out 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.		** If it's not possible to identify the guilty changeset, the sheriffs may back out 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.

Stephend: /* Sheriff Duty */

2019-09-12T22:30:25Z

Sheriff Duty

← Older revision		Revision as of 22:30, 12 September 2019
Line 32:		Line 32:
	= Sheriff Duty =		= Sheriff Duty =
	* Sheriffs will watch these trees (mozilla-inbound and autoland) 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 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.		** If it's not possible to identify the guilty changeset, the sheriffs may back out 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.
	* 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.

Agashlin: Fix typo, broken link

2018-08-07T18:06:49Z

Fix typo, broken link

← Older revision		Revision as of 18:06, 7 August 2018
Line 1:		Line 1:
	= What are integration repositories? =		= What are integration repositories? =

	Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration ~~branch~~ that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.		Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration branches that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.

	= Working with integration repositories =		= Working with integration repositories =
Line 10:		Line 10:

	= What are the tree rules for integration repositories? ==		= What are the tree rules for integration repositories? ==
	* Follow the '''[https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'':		* Follow the '''[https://developer.mozilla.org/en-US/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'':
	** Committers are ''not'' required to actively watch the tree after pushing to an integration repository.		** Committers are ''not'' required to actively watch the tree after pushing to an integration repository.
	** Checking [https://treeherder.mozilla.org/ Treeherder] before pushing is not required, but it is appreciated. If the tree is in a very broken state, you can save the sheriffs work by notifying them instead of pushing.		** Checking [https://treeherder.mozilla.org/ Treeherder] before pushing is not required, but it is appreciated. If the tree is in a very broken state, you can save the sheriffs work by notifying them instead of pushing.

ChrisCooper: /* Sheriff Duty */

2017-07-19T18:09:44Z

Sheriff Duty

← Older revision		Revision as of 18:09, 19 July 2017
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.

ChrisCooper: /* Working with integration repositories */

2017-07-18T21:39:10Z

Working with integration repositories

← Older revision		Revision as of 21:39, 18 July 2017
Line 4:		Line 4:

	= Working with integration repositories =		= Working with integration repositories =
	It is recommended that you use the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html Unified Firefox Repository]		It is recommended that you use the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html Unified Firefox Repository] for landing to mozilla-inbound.
	* https://hg.mozilla.org/mozilla-unified/		* https://hg.mozilla.org/mozilla-unified/

			Unless you're a sheriff or something has gone horribly wrong, you shouldn't need to clone the autoland repo.

	= What are the tree rules for integration repositories? ==		= What are the tree rules for integration repositories? ==

ChrisCooper at 21:37, 18 July 2017

2017-07-18T21:37:53Z

← Older revision		Revision as of 21:37, 18 July 2017
Line 1:		Line 1:
	== What are integration repositories? ==		= What are integration repositories? =

	Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration branch that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.		Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration branch that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.

	* eg: http://hg.mozilla.org/integration~~/mozilla-inbound~~		= Working with integration repositories =
	** To speed up the cloning you ~~can~~ use the [~~ftp~~:/~~/ftp.mozilla.org/pub/mozilla.org/firefox/bundles~~/mozilla-~~inbound~~.~~hg bundle] ([https://developer.mozilla~~.~~org~~/en/~~Mozilla_Source_Code_%28Mercurial%29#Bundles instructions]) or see [http:~~//~~jlebar.com/2011/5/20/Faster_and_smaller_clones_of_branches~~.html ~~this blog post~~].		It is recommended that you use the [http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html Unified Firefox Repository]
	* ~~http~~://~~tbpl~~.mozilla.org/~~?tree=Mozilla~~-~~Inbound~~		* https://hg.mozilla.org/mozilla-unified/

	~~== What are the tree rules for integration repositories? ==~~

			= What are the tree rules for integration repositories? ==
	* Follow the '''[https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'':		* Follow the '''[https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'':
	** Committers are ''not'' required to actively watch the tree after pushing to an integration repository.		** Committers are ''not'' required to actively watch the tree after pushing to an integration repository.
Line 19:		Line 18:
	** It is recommended to have a separate local clone. Pull to it, apply your patches, and then push to the integration repository.		** It is recommended to have a separate local clone. Pull to it, apply your patches, and then push to the integration repository.

	== Please do the following after pushing to an integration repository ==		= Please do the following after pushing to an integration repository =
	* '''Leave bugs open'''. The sheriff will resolve them when they are merged to m-c.		* '''Leave bugs open'''. The sheriff will resolve them when they are merged to m-c.
	* '''Add the "leave-open" keyword''' if the bug should not be resolved fixed after the merge to m-c. (We're now using a new semi-automated tool - bug comments won't be seen).		* '''Add the "leave-open" keyword''' if the bug should not be resolved fixed after the merge to m-c. (We're now using a new semi-automated tool - bug comments won't be seen).
Line 29:		Line 28:
	* There is no need to add "[inbound]" to the status whiteboard any more, but you may still do so if it helps with tracking your assigned bugs.		* There is no need to add "[inbound]" to the status whiteboard any more, but you may still do so if it helps with tracking your assigned bugs.

	== Sheriff Duty ==		= Sheriff Duty =

	* Sheriffs will watch this tree and back out bustage/regressions as necessary to keep it green.		* Sheriffs will watch this tree 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".
Line 42:		Line 40:
	** 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.

	== Meet the Sheriffs ==		= Meet the Sheriffs =
			The integration repositories are managed by group of sheriffs, please be nice with them. If you have any doubts or questions about the above process, you can ping any of them in #developers channel.
	The integration repositories are managed by group of sheriffs, please be nice with them.
	~~In case of~~ doubts you can ping any of them in #developers channel.

	For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs\|Meet the Sheriffs]].		For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs\|Meet the Sheriffs]].

ChrisCooper at 21:07, 18 July 2017

2017-07-18T21:07:58Z

Archaeopteryx: removed reference to b2g-inbound

2016-03-04T17:50:38Z

removed reference to b2g-inbound

← Older revision		Revision as of 17:50, 4 March 2016
Line 1:		Line 1:
	== What are integration repositories? ==		== What are integration repositories? ==

	Repositories such as mozilla~~-inbound, b2g~~-inbound & fx-team are integration branch that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.		Repositories such as mozilla-inbound & fx-team are integration branch that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.

	* eg: http://hg.mozilla.org/integration/mozilla-inbound		* eg: http://hg.mozilla.org/integration/mozilla-inbound

Edmorley: /* Meet the Sheriffs */ Move list of sheriffs to the sheriffing page

2014-12-13T14:12:51Z

Meet the Sheriffs: Move list of sheriffs to the sheriffing page

← Older revision		Revision as of 14:12, 13 December 2014
Line 45:		Line 45:
	== Meet the Sheriffs ==		== Meet the Sheriffs ==

	~~Integration repository is~~ managed by group of sheriffs, please be nice with them.		The integration repositories are managed by group of sheriffs, please be nice with them.
	In case of doubts you can ping any of them in #developers channel.		In case of doubts you can ping any of them in #developers channel.

	* UTC+5:30: Nigel Babu [:nigelb]		For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs]].
	* UTC+1: Carsten Book [:Tomcat]
	* UTC+1: Ms2ger (who denies being a sheriff unless it suits him)
	* UTC-4: Ryan VanderMeulen [~~:RyanVM]~~
	* UTC-8: Wes Kocher [~~:KWierso~~]
	* UTC-8: Phil Ringnalda [:philor]

	~~Join us and help out!~~

	~~For more info on what's happening at the moment, see:~~
	~~https://sheriffs.etherpad.mozilla~~.~~org/sheriffing-notes~~

Edmorley: /* Meet the Sheriffs */ List sheriffs in timezone order & remove edmorley

2014-12-13T13:56:47Z

Meet the Sheriffs: List sheriffs in timezone order & remove edmorley

← Older revision		Revision as of 13:56, 13 December 2014
Line 48:		Line 48:
	In case of doubts you can ping any of them in #developers channel.		In case of doubts you can ping any of them in #developers channel.

	* ~~Ed Morley [:edmorley] -~~ UTC+0		* UTC+5:30: Nigel Babu [:nigelb]
	* Ryan VanderMeulen [:~~RyanVM~~] ~~- UTC-4~~		* UTC+1: Carsten Book [:Tomcat]
	* ~~Phil Ringnalda [~~:~~philor] - UTC-8~~		* UTC+1: Ms2ger (who denies being a sheriff unless it suits him)
	* Carsten Book [:Tomcat] - UTC+1		* UTC-4: Ryan VanderMeulen [:RyanVM]
	* Wes Kocher [:~~KWierso] - UTC-7~~		* UTC-8: Wes Kocher [:KWierso]
	* Ms2ger (who denies being a sheriff unless it suits him) - ~~UTC+1~~		* UTC-8: Phil Ringnalda [:philor]
	* ~~Nigel Babu~~ [:~~nigelb~~] - ~~UTC+5~~:30

	Join us and help out!		Join us and help out!

← Older revision		Revision as of 21:07, 18 July 2017
Line 1:		Line 1:
	== What are integration repositories? ==		== What are integration repositories? ==

	Repositories such as mozilla-inbound ~~& fx~~-~~team~~ are integration branch that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.		Repositories such as [https://treeherder.mozilla.org/#/jobs?repo=autoland autoland] and [https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound mozilla-inbound] are integration branch that merge to and from mozilla-central about once a day. They're a place where changes can land and be tested without risk of breaking the main mozilla-central trunk.

	* eg: http://hg.mozilla.org/integration/mozilla-inbound		* eg: http://hg.mozilla.org/integration/mozilla-inbound
Line 11:		Line 11:
	* Follow the '''[https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'':		* Follow the '''[https://developer.mozilla.org/En/Developer_Guide/Committing_Rules_and_Responsibilities general rules for committing]''', ''except'':
	** Committers are ''not'' required to actively watch the tree after pushing to an integration repository.		** Committers are ''not'' required to actively watch the tree after pushing to an integration repository.
	** Checking [https://treeherder.mozilla.org/ Treeherder] before pushing is not required, but it is appreciated. If the tree is in a very broken state, you can save the sheriffs work by notifying them instead of pushing.		** Checking [https://treeherder.mozilla.org/ Treeherder] before pushing is not required, but it is appreciated. If the tree is in a very broken state, you can save the sheriffs work by notifying them instead of pushing.
	* Integration repositories are no replacement for ~~'''~~[[Try]]'''. You still need to test your patches before pushing. (This doesn't mean that you need an all-platforms try run for every patch~~. But~~ it does mean that you should do enough testing so that you rarely cause red or orange on the integration repository. ~~But breaking~~ it rarely is ok. ~~Never missing a plane means~~ you~~'re spending too much time in airports; never breaking~~ the ~~tree means you're running too many tests before landing~~.)		* '''Integration repositories are no replacement for [[Try]]'''. You still need to test your patches before pushing. This doesn't mean that you need an all-platforms try run for every patch, but it does mean that you should do enough testing so that you rarely cause red or orange on the integration repository. Breaking it rarely is OK.
			** The exception is if you are using the autoland integration with MozReview [[http://mozilla-version-control-tools.readthedocs.io/en/latest/mozreview/autoland.html#sending-commits-to-try send your commits to the Try server automatically]].
	* When can I push to the tree? '''Always!'''		* When can I push to the tree? '''Always!'''
	** If there is something very wrong with the integration repository, a sheriff will close the tree, and your push will fail automatically.		** If there is something very wrong with the integration repository, a sheriff will close the tree, and your push will fail automatically.
	* Push to it like any separate hg repo~~: it~~ is recommended to have a separate local clone. Pull to it, apply your patches, and then push to the integration repository.		* Push to it like any separate hg repo.
			** It is recommended to have a separate local clone. Pull to it, apply your patches, and then push to the integration repository.

	== Please do the following after pushing to an integration repository ==		== Please do the following after pushing to an integration repository ==

	* '''Leave bugs open'''. The sheriff will resolve them when they are merged to m-c.		* '''Leave bugs open'''. The sheriff will resolve them when they are merged to m-c.
	* '''Add the "leave-open" keyword''' if the bug should not be resolved fixed after the merge to m-c. (We're now using a new semi-automated tool - bug comments won't be seen).		* '''Add the "leave-open" keyword''' if the bug should not be resolved fixed after the merge to m-c. (We're now using a new semi-automated tool - bug comments won't be seen).
Line 27:		Line 28:
	* If you backout from an integration repository, annotate that in the bug. This helps sheriffs when merging.		* If you backout from an integration repository, annotate that in the bug. This helps sheriffs when merging.
	* There is no need to add "[inbound]" to the status whiteboard any more, but you may still do so if it helps with tracking your assigned bugs.		* There is no need to add "[inbound]" to the status whiteboard any more, but you may still do so if it helps with tracking your assigned bugs.

	~~Thanks :-)~~

	== Sheriff Duty ==		== Sheriff Duty ==
Line 48:		Line 47:
	In case of doubts you can ping any of them in #developers channel.		In case of doubts you can ping any of them in #developers channel.

	For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs]].		For the list of people to look out for, see [[Sheriffing#Meet_the_Sheriffs\|Meet the Sheriffs]].