Release stabilization: Create backport issues immediately

[Wei-Jun Wang]

Or, we can still fix in the main line first and backport it. Only, let Skara do something different.

Suppose I keep the bug’s target to jdk22, currently the Skara bot is already able to notice it and shows a warning in the jdk23 PR. When the jdk23 PR is integrated, I wonder if the bot can:

1. Change the JBS target to 23, where the fix is integrated
2. Create a backport for 22, which is the original target

If I remember correctly, its current behavior is to keep the original bug unchanged and create a “backport” for jdk23. If we believe that backport is always backward, this should be fixed anyway. If we believe a backport can be forward, then all is fine. The bug id used in the comment is still the non-backport one.

Thanks,
Weijun

p.s. From what Mark said "so that Skara will close the correct issue", it seems backport should only be backward.



> On Dec 13, 2023, at 10:44 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> 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
> 
>