Release stabilization: Create backport issues immediately

[Joe Darcy]

To summarize the multi-release model used in JBS, while Jira does allow 
multiple values for the fixVersions field, we viewed that as inadequate 
for bug management purposes. For example, we want to know status of the 
bug _for a given release_, what build the fix is present in _for a given 
release_, etc.

Since Jira does not offer a per-release tuple like (status, 
fixed-in-build, ...) we implement this functionality using separate 
backport issues.

When the CSR process was first rolled out, we followed the general 
guidance of only using a single release values, but the constraints of a 
CSR are different and using a single CSR for multiple releases, subject 
to the requirements discussed in the CSR wiki page, was a least-bad option.

HTH,

-Joe

On 12/14/2023 4:13 AM, Kevin Rushforth wrote:
> That would just cause more confusion. None of our tools or queries are 
> set up to work well in the presence of multiple fix versions.
>
> -- Kevin
>
>
> On 12/13/2023 5:52 PM, dean.long at oracle.com wrote:
>>
>> On 12/13/23 6:18 AM, Mark Reinhold wrote:
>>
>>>      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.
>>
>>
>> JIRA seems to allow multiple Fix Versions, so I'm wondering if the 
>> fix versions were set to main-line /and/ 22, would Skara PR logic and 
>> candidate-bug queries do the right thing, or would it just cause more 
>> confusion?
>>
>> dl
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20231214/769aa3fa/attachment.htm>