Release stabilization: Create backport issues immediately

[Mark Reinhold]

Last May, for JDK 21, we adopted Erik Duveblad’s proposal to use the
Skara backport mechanism to stabilize the release after RDP 1 [1][2]:

> Erik proposes that we instead use the Skara backport mechanism, which
> we already use for update releases.  To fix a bug in the release being
> stabilized you’d first create a PR against the main-line repository.
> Then, after that PR is reviewed and integrated, you’d use Skara’s
> `/backport` command to backport the fix to the stabilization repository.
> If your fix is intended only for the stabilization repository then you’d
> create a PR directly against that repository.

This worked out reasonably well for JDK 21, except for one problem.

Suppose that you have a candidate bug [3] that you want to fix in the
stabilization release (e.g., JDK 22).  Before you merge the PR against
the main-line repository, you change the fix version of that bug to that
of the main-line release (e.g., JDK 23) so that Skara will close the
correct issue.  This causes the bug to disappear from the results of the
candidate-bug queries [4] that we use to guide our work in the RDP 1,
RDP 2, and RC phases, leaving us at risk of losing track of the bug for
the stabilization release.

In JDK 21, various Committers worked around this in different ways, for
example by using JIRA labels.  The difficulty with labels is that you
have to remember to remove them when they’re no longer applicable, which
makes the overall process more complex.

For JDK 22, let’s instead try the following small adjustment to the
integration procedure:

    To fix a bug in the stabilization release, first target that bug to
    the main-line release and **immediately create a backport of the bug
    and target the backport to the stabilization release.**  Then create
    a PR to integrate your fix into the main-line release.  After you
    have obtained any necessary approvals, backport the main-line PR to
    the stabilization repository via the Skara `/backport` command.

    (As before, if your fix is intended only for the stabilization
     repository then target the bug to the stabilization release and
     create a PR directly against that repository.)

We will also update the candidate-bug queries to include issues of type
“Backport” as well as “Bug”.  These changes will ensure that a bug
relevant to the stabilization release remains on the appropriate
candidate-bug lists.  Its issue number will change when the fix is
integrated into the main-line repository, but at least we won’t lose
track of it.

Comments welcome, as always, but we’re already in RDP 1 so I suggest
that we start using this process immediately and adjust if necessary.
I’ve already updated the candidate-bug queries; I’ll update JEP 3
shortly.

- Mark


[1] https://mail.openjdk.org/pipermail/jdk-dev/2023-April/007612.html
[2] https://mail.openjdk.org/pipermail/jdk-dev/2023-May/007822.html
[3] https://openjdk.org/jeps/3#Candidate-bugs
[4] https://j.mp/jdk-rdp-1, https://j.mp/jdk-rdp-2, https://j.mp/jdk-rc