RFR: No localization in RDP2 [v2]

[Alexey Ivanov]

On Fri, 14 Mar 2025 00:32:20 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Localization can't be expected for changes made in RDP2.
>> 
>> @irisclark This change also contain your fixes from #145 that I apparently didn't commit before integrating.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in label

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

> 338: ### Closing incomplete issues
> 339: 
> 340: As mentioned above, issues that lack the information needed to investigate the problem are placed in status [Resolved]{.jbs-value} - [Incomplete]{.jbs-value}. Triage teams should monitor incomplete issues in their area and if needed ping the relevant person. When new information is received, the bug should be returned to status [Open]{.jbs-value}. If the required information hasn't been obtained within reasonable time (3-4 weeks) the bug should be closed as [Incomplete]{.jbs-value}.

Does “…the bug should be closed…” imply that the *Resolved* status changes to *Closed*?

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

> 432:                            [*(Rel)*[-fix-no]{.jbs-label}]{#rel-fix-no}</td>
> 433:     <td class="dictionary">
> 434:       *(Rel)*[-fix-request]{.jbs-label} is used in ramp down phase 2 to indicate that an issue would be of interest to be integrated into release *(Rel)*. E.g., [jdk12-fix-request]{.jbs-label}

Should the section be expanded for update releases? The labels like `jdk12u-fix-request` and `jdk24u-fix-request` are constantly used to [request approval for backporting](https://openjdk.org/guide/#requesting-approvals-for-backports) an update release.

The `jdk##-fix-request` and `jdk##u-fix-request` are similar, but they have a different role in the OpenJDK Project.

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

> 435: 
> 436:       *(Rel)*[-fix-SQE-ok]{.jbs-label} is used to indicate that the issue will be covered by the test plan for *(Rel)*. E.g., [jdk12-fix-SQE-ok]{.jbs-label}<br />
> 437:       *(Rel)*[-fix-yes]{.jbs-label} and *(Rel)*[-fix-no]{.jbs-label} are used to indicate wether an issue has been approved for backport to *(Rel)*. E.g., [jdk12-fix-yes]{.jbs-label}

Yet `jdk12-fix-yes` isn't applicable to backports, it's for post RDP2 integrations (which are also *backports* since the initial fix goes to mainline which is at *Rel+1*). Maybe a different wording should be used to clarify…

src/guide/making-a-change.md line 73:

> 71: ## Changes Late in the Release
> 72: 
> 73: You should always aim to get your changes integrated as early in a release as possible to maximize the amount of testing done before release. If you risk running late it's almost always a better idea to defer the change to the next release rather than trying to squeeze it in in the last minute. The next release is only six months out, the world can wait even though you are eager.

Suggestion:

You should always aim to get your changes integrated as early in a release as possible to maximize the amount of testing done before release. If you risk running late, it's almost always a better idea to defer the change to the next release rather than trying to squeeze it in in the last minute. The next release is only six months away, the world can wait even though you are eager.


A comma after the conditional cause which comes before the main clause helps reading.

I think “away” is correct when you're referring to an upcoming release; whereas “out” would imply an already released version six months ago.

*“…to squeeze it in in the last minute”* could be hard to read because of two adjacent ‘in’s.

src/guide/making-a-change.md line 75:

> 73: You should always aim to get your changes integrated as early in a release as possible to maximize the amount of testing done before release. If you risk running late it's almost always a better idea to defer the change to the next release rather than trying to squeeze it in in the last minute. The next release is only six months out, the world can wait even though you are eager.
> 74: 
> 75: Integrating during the rampdown phase is not recommended. The bar to integrate a change in the rampdown phase is considerably higher than during the normal development phase. See [The JDK Release Process] for more information. Also note that changes that are made late in the release shouldn't expect localization since this in itself takes some time.

Suggestion:

Integrating during the rampdown phase is not recommended. The bar to integrate a change in the rampdown phase is considerably higher than during the normal development phase. See [The JDK Release Process] for more information. Also note changes that are made late in the release shouldn't expect localization since this in itself takes some time.


Is the last sentence easier to read and understand if you omit the relative conjunction ‘that’?

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

PR Review Comment: https://git.openjdk.org/guide/pull/146#discussion_r1995847429
PR Review Comment: https://git.openjdk.org/guide/pull/146#discussion_r1995875143
PR Review Comment: https://git.openjdk.org/guide/pull/146#discussion_r1995880459
PR Review Comment: https://git.openjdk.org/guide/pull/146#discussion_r1995892111
PR Review Comment: https://git.openjdk.org/guide/pull/146#discussion_r1995898511