Release stabilization: Create backport issues immediately

[Pavel Rappo]

One disadvantage of the proposed adjustment I see is the need to create a JBS backport issue manually. (Unless I'm mistaken.) Not that it's difficult, but it's error-prone. In contrast, when using Skara /backport command, the JBS backport issue is created automatically.

Why can't we just _forward port_ an issue to the main-line using the same Skara /backport command, but with the benefits of automation? Fix your issue in the stabilisation repo first and then forward port it to the main-line. In this case, you don't even need any additional approvals, right? Unless, of course, people object to having "Backport-of" commits in the main-line repo. (Speaking of which, we already have 25 of such commits there.)

> On 13 Dec 2023, at 14:18, Mark Reinhold <mark.reinhold at oracle.com> wrote:
> 
> 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