Skip to content

Fix links to #trivial-changes #156

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed

Fix links to #trivial-changes #156

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
0880c2d
Fix links to trivial-changes
mhaessig Aug 4, 2025
84cd17a
Update src/guide/testing-the-jdk.md
mhaessig Aug 7, 2025
e791051
Update src/guide/testing-the-jdk.md
mhaessig Aug 7, 2025
bc4dbab
Apply suggestions from code review
mhaessig Aug 7, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions src/guide/testing-the-jdk.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -289,7 +289,7 @@ In this example, `MyTest.java` is excluded, tracked by bug `JDK-4711`. `@ignore`

ProblemListing and `@ignore`-ing are done in the JDK source tree, that means a check-in into the repository is needed. This in turn means that a unique JBS issue and a code review are needed. This is a good thing since it makes test problems visible.

* **Code review**: ProblemListing a test is considered a [trivial](#trivial) change.
* **Code review**: ProblemListing a test is considered a [trivial change](#trivial-changes).
* **JBS issue**: A JBS issue is obviously created for the bug that caused the failure, we call this the _main issue_. To exclude the test, create a subtask to the main issue. Also add the label [[problemlist]{.jbs-label}](#problemlist) to the main issue.

The fix for the main issue should remove the test from the ProblemList or remove the `@ignore` keyword from the test.
Expand All @@ -304,7 +304,7 @@ If a change causes a regression that can't be fixed within reasonable time, the

It will happen of course when the build is broken or the JDK is DOA and similar situations that a change is immediately backed out without further investigation. Backing out a change is however seldom the first course of action if the change has been done in accordance with the guidance in [Working With Pull Requests]. If, when investigated, it is found that a change didn't go through relevant testing or there are other issues that should have been caught before integration if proper procedure had been followed, it's quite possible that a change is backed out even if the author is desperately working on a fix. The JDK source code is deliberately menat to have a high bar for acceptance of changes. If something crawls in underneath that bar it should most likely be backed out.

The backout is a regular change and will have to go through the standard code review process, but is considered a [trivial](#trivial) change. The rationale is that a backout is usually urgent in nature and the change itself is automatically generated. In areas where two reviewers are normally required, only one [Reviewer](https://openjdk.org/bylaws#reviewer) is required for a backout since the person who is performing the backout also should review the change.
The backout is a regular change and will have to go through the standard code review process, but is considered a [trivial change](#trivial-changes). The rationale is that a backout is usually urgent in nature and the change itself is automatically generated. In areas where two reviewers are normally required, only one [Reviewer](https://openjdk.org/bylaws#reviewer) is required for a backout since the person who is performing the backout also should review the change.

There are two parts to this task, how to do the bookkeeping in JBS, and how to do the actual backout in git.

Expand Down