RFR: Requesting a change [v8]

Wed Aug 6 18:48:37 UTC 2025

On Tue, 5 Aug 2025 23:18:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Advice for people who would like to request an OpenJDK change to be implemented or backported.
>> Also added a note about having more than one noreg-label.
>> HotSpot issues in JBS must have a Subcomponent set.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typos

Changes requested by aivanov (no project role).

src/guide/contributing-to-an-open-jdk-project.md line 13:

> 11: ## Requesting a change
> 12: 
> 13: If you want to request a change to the JDK, but don't have the intention to implement/contribute to the change yourself, you should always report it at [bugreport.java.com](bugreport.java.com). This is also the case if you find a change that you would like to see backported to an earlier JDK release. **Never** reach out directly to any developer. Also, please note that the [OpenJDK mailing lists](#mailing-lists) are intended for developers and contributors. These lists are not support channels or channels for requesting changes.

It's still unclear what a person should do to request backporting a fix. Is it recommended to submit a new bug?

src/guide/contributing-to-an-open-jdk-project.md line 46:

> 44: 
> 45: - As with any change, do bring it up for discussion on the [mailing lists](#mailing-lists) before spending time on the fix. Even though the issue has been filed in JBS there may be reasons not to fix that particular issue right now.
> 46: - Never work on an issue that is assigned to someone else. Duplicating work is pointless. If you think that an issue should be fixed and it has been assinged to someone for a long time without progress, reach out to that person and ask what the current status is. Many issues requires a lot of thought, and there may be half-baked solutions that you can build on to avoid the traps the initial developer has already fallen into.

Suggestion:

- Never work on an issue that is assigned to someone else. Duplicating work is pointless. If you think that an issue should be fixed and it has been assigned to someone for a long time without progress, reach out to that person and ask what the current status is. Many issues requires a lot of thought, and there may be half-baked solutions that you can build on to avoid the traps the initial developer has already fallen into.

src/guide/jbs-jdk-bug-system.md line 217:

> 215: 1. If the issue is a duplicate, close it as such.
> 216: 1. If the issue belongs to a different area (it was filed in libraries, but it's an HotSpot issue), transfer it to the correct component/subcomponent making sure that the state remains [New]{.jbs-value}.
> 217:    * Please note that issues in the [hotspot]{.jbs-value} and [security-libs]{.jbs-value} components must have a [Subcomponent]{.jbs-field} set as well.

@irisclark is right, it's advisable to set a subcomponent for issues in client-libs. However, it's not required as far as I can tell. There are issues where subcomponent isn't set, in majority of cases this is likely because the issue is too broad and is applicable to the entire client area.

src/guide/jbs-jdk-bug-system.md line 652:

> 650:                            [[nounit-]{.jbs-label}`.*`]{#nounit}</td>
> 651:     <td class="dictionary">
> 652:       The [noreg-]{.jbs-label}`.*` and [nounit-]{.jbs-label}`.*` labels are used to explain why a change doesn't need/have a regression test or a unit test. The suffix of the label is described below. Every change that is integrated into the JDK source code must either have a regression/unit test, or have at least one of these labels on its JBS issue. It's quite possible to have more than one of these labels on the same issue. For instance, an integration could contain both changes to documentation and test code. In that case it would be logical to label the issue with both [noreg-doc]{.jbs-label} and [noreg-self]{.jbs-label}.

Suggestion:

      The [noreg-]{.jbs-label}`.*` and [nounit-]{.jbs-label}`.*` labels are used to explain why a change doesn't need/have a regression test or a unit test. The suffix of the label is described below. Every change that is integrated into the JDK source code must either have a regression/unit test, or have at least one of these labels on its JBS issue. It's possible to have more than one of these labels on the same issue. For instance, a changeset could contain both changes to documentation and test code. In that case it would be logical to label the issue with both [noreg-doc]{.jbs-label} and [noreg-self]{.jbs-label}.

“An integration” sounds confusing. To avoid having “changeset” and “changes” close in one sentence, you could state: “a change could modify both…”

“Quite” doesn't clarify the meaning, the sentence is clearer without it.

-------------

PR Review: https://git.openjdk.org/guide/pull/155#pullrequestreview-3093763213
PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2257968034
PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2257971819
PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2257964308
PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2257988340