RFR: Using backports for stabilization repositories

[Jesper Wilhelmsson]

On Fri, 9 Jun 2023 04:30:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When backporting to the release stabilization repository, as opposed to an update release repository, there is no specific backport approval process, but a particular issue may need specific approval due to the nature of the issue and which stage of rampdown we are in (e.g. late enhancements).

The approval processes is described in JEP 3 and in the section "The JDK Release Process". I've added a reference to that.

> If we have a candidate issue for the release stabilization repo, which we will have to push to mainline first, should we be marking the JBS issue somehow to show that the backport is intended to be done? With the old system we would keep an issue targeted to the older release in general and the forward-port would create the backport issue for the new release. With the new scheme the JBS issue should be targeted to the latest release and so you can't tell by looking at that if there is any intent to backport it.

The default assumption is that all bugfixes that are pushed to mainline during rampdown should be backported to the release in rampdown as well, so no extra work is needed to tag these. The things to tag are issues that should not be backported either because they are new in mainline (set Introduced in version to the mainline JDK version) or because they have been deferred out from the rampdown release and have the jdkN-deferred-yes label.
Wether this exact process works and all the details are still to be figured out. We'll see how this is formalized going forward.

I have created #108 to fix issues in this new policy.

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

PR Comment: https://git.openjdk.org/guide/pull/105#issuecomment-1611661495