RFR: Cleanups and fixes

[Chen Liang]

On Tue, 30 Sep 2025 19:10:10 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Various cleanups and fixes:
> * Removed the "ToDo" from the README - it's been there from the start and had some random things suggested for improvement at the time but it hasn't guided the work or what we have focused on in the guide. It also wasn't updated when changes were made so by now it was mainly outdated.
> * Removed the mention of LTS releases since this is not an OpenJDK concept.
> * Updated Sponsor links in the context of sponsoring a change, the links were referring to the description of sponsoring a Project.
> * Added a note on using N-pool values for FixVersion.
> * Cleaned up description of AffectsVersion.
> * Removed "Things to keep in mind when requesting an improvement" which is already covered in [Contributing to an OpenJDK Project](https://openjdk.org/guide/#contributing-to-an-openjdk-project)
> * Changed backout process to not use sub-tasks.
> * Fixed minor typos etc.

src/guide/code-owners.md line 3:

> 1: # Code Owners
> 2: 
> 3: This list is intended to make it easier to identify which email list to include in code reviews when making changes in different areas. The list may also help when assigning bugs based on which code they are found in. Please note that some directories may have been created or removed between releases. The intention here is to include directories that exists in mainline and other releases (post JDK 9) commonly being updated.

Should we specify that "commonly being updated" means being updated by jdk-updates project?

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

> 81:     - Note that if it's reported against an update release then all we can say is that it's applicable to all the following update releases, not necessarily the next feature release as it may have been introduced in an update. Given this, it is always important to try and reproduce the issue in the corresponding feature release as well as mainline.
> 82: 
> 83: 1) If an issue is applicable to release N, then it can't be assumed that it is applicable to older releases less than N. It may be, but in general this is less important to know, as the majority of issues are only fixed in the latest feature release. If the issue is a crash or important in another way, then it becomes worthwhile to take the time to determine if it's relevant to earlier maintained releases.

Maybe say explicitly "earlier releases maintained by the jdk-updates project"?

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

PR Review Comment: https://git.openjdk.org/guide/pull/159#discussion_r2392655139
PR Review Comment: https://git.openjdk.org/guide/pull/159#discussion_r2392649582