Analyzing and handling critical failures has high priority. The expected turnaround time to resolve an issue is before the next nightly starts, but should be handled in the most reasonable fashion, given our distributed community. Handling a failure means fixing the bug that caused the failure or backing out the change that caused the failure. In exceptional cases it can mean quarantining the test or ask for quarantine exception, especially reasonable in case of long time intermittent issues.

How strict to be is decided on a case by case basis, but all pushes must be done with care, since failing tests may be harder to isolate and handle when more changes are coming in. If the situation is too bad the repository can be locked, but if the issue is isolated and the risk for complications is low, it may be better not to block additional changes being pushed.

A repository where new failures (a.k.a. integration blockers) have been seen in testing must not be pushed upstream. Failures must not spread and interfere with other engineers' development. This goes for both project repositories that integrate with jdk/hs, and jdk/hs itself as it integrates with jdk/jdk. Please note that there is no difference between product bugs and test bugs when it comes to integration blockers.