RFR: Using backports for stabilization repositories

[Jesper Wilhelmsson]

On Wed, 31 May 2023 18:34:03 GMT, Erik Helin <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that replaces the documentation on the "forward ports" process with the [recently adopted](https://mail.openjdk.org/pipermail/jdk-dev/2023-May/007889.html) "backports" process. The changes are fairly small since the guide already contains great documentation on backports, I just had to adopt it slightly to also cover stabilization repositories.
> 
> Thanks!
> Erik

Thank you for updating the guide with respect to the new policy! A few comments below.

src/guide/backporting.md line 12:

> 10: Development of the latest version of the JDK often results in bug fixes that might be interesting to include in some of the JDK update releases still being maintained or in a [release stabilization repository](https://openjdk.org/guide/#backporting-to-release-stabilization-fork). Moving a fix from a more recent release train (e.g. JDK 17) to an older release train (e.g. JDK 11) is called *backporting*.
> 11: 
> 12: The guideline for what to backport into a specific release will vary over the lifetime of that release. Initially more fixes are expected to be backported as new features and large changes introduced in a mainline release stabilize. Over time the focus will shift from stabilization to keeping it stable - the release will go into maintenance mode. This means that bug fixes that require larger disruptive changes are more likely to be made in mainline and backported to more recent release trains only, and not to older release trains. Release stabilization repositories (e.g. [jdk20](https://git.openjdk.org/jdk20)) follows the process described in [JEP 3](https://openjdk.org/jeps/3) for deciding the bug fixes that should be backported.

JEP 3 only sets the limits of what may and may not be included during rampdown, it doesn't give any hints of how to decide if a particular bugfix should be included. The developer of a fix will still need to decide if the change should go into the stabilization repo or not.

src/guide/the-jdk-release-process.md line 53:

> 51: Please note that the priority of a bug doesn't change just because you want to get your fix in late in the release, or if you want to be able to defer it. The priority is based on the severity of the bug and if it was deemed to be a P2 before, you better have a really good explanation to why that conveniently has changed by the end of the release. Being hard to fix is **not** a reason to lower the priority of a bug.
> 52: 
> 53: ## Backporting to release stabilization repository

This section is now unrelated to the particulars of the JDK release process and should be moved to the Backporting chapter instead. I suggest to place it after the section about working with Skara tooling.
Please add "a" (...to a release...) in the title.

src/guide/the-jdk-release-process.md line 55:

> 53: ## Backporting to release stabilization repository
> 54: 
> 55: During the rampdown of a release there are two repositories in play, the release stabilization repository for the outgoing release, and the mainline repository where the next release is being developed. Any bugfix going into the release stabilization repository is likely to be desired in mainline as well. As a developer you should always create a pull request targeting the mainline repository first and then, once the pull request is integrated, [backport](https://openjdk.org/guide/#backporting) the resulting commit to the release stabilization repository. For bugfixes that are **only** applicable to the release stablization repository, regular pull requests targeting the stabilization fork should be created.

The last sentence "For bugfixes that..." is unrelated to backporting and can be removed. I'm not sure if there is some other place to put such a note, but I don't think it needs to be explicitly mentioned. This is the same for any release repository (e.g. update releases - if a fix is needed in JDK 17u only it's integrated only there).

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

PR Review: https://git.openjdk.org/guide/pull/105#pullrequestreview-1453925826
PR Review Comment: https://git.openjdk.org/guide/pull/105#discussion_r1212183591
PR Review Comment: https://git.openjdk.org/guide/pull/105#discussion_r1212183325
PR Review Comment: https://git.openjdk.org/guide/pull/105#discussion_r1212182997