Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Warning |
---|
DeprecatedThis page is deprecated and it's content is either old or being moved to the OpenJDK Developers' Guide. Please update your links. |
Tip | ||
---|---|---|
| ||
|
Hotspot Gatekeeping Policy - Three Golden Rules
Note | ||
---|---|---|
| ||
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. |
Note | ||
---|---|---|
| ||
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. |
Note | ||
---|---|---|
| ||
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 |
Info | ||
---|---|---|
| ||
Info | ||
---|---|---|
| ||
Info | ||
---|---|---|
| ||
Info | ||
---|---|---|
| ||