Sheriffing/Deciding To Close A Tree: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
* Excessive backlog for builds or tests in any platform | * Excessive backlog for builds or tests in any platform | ||
* Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues) | * Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues) | ||
* Mass "bustage" that could hide other test failures (this is when code lands and causes multiple tests to fail across multiple chunks of tests or suites of tests, making it harder to catch further failures if something else lands *during* the period in which these tests are failing from the original code landing) | |||
Revision as of 18:43, 24 May 2016
=Deciding to close a tree
Many objective and subjective criteria are part of deciding to close a tree. Tree closure means that developers are prevented from pushing or merging code to a codebase. Later, sheriffs will reopen the trees when the problem appears to be resolved.
Some of the criteria used include:
- Broken build on an integration or main tree (e.g. mozilla-inbound, mozilla-central, fxteam)
- Excessive backlog for builds or tests in any platform
- Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues)
- Mass "bustage" that could hide other test failures (this is when code lands and causes multiple tests to fail across multiple chunks of tests or suites of tests, making it harder to catch further failures if something else lands *during* the period in which these tests are failing from the original code landing)