RFR: Backporting related changes [v2]

[Jesper Wilhelmsson]

On Thu, 27 Jun 2024 00:27:51 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed review comments
>
> src/guide/backporting.md line 57:
> 
>> 55: There can be cases where it's desirable to create a backport issue before the fix is done, e.g. if a CSR needs to be filed. In these cases set the [Fix Version/s]{.jbs-field} of the backport to `N` or `N-pool`, where `N` is the release train the backport is targeting. E.g. `17-pool`. Please note that even if a backport issue is created ahead of time, all work done in JBS for approvals and similar is still done in the main issue.
>> 56: 
>> 57: Obviously it's possible to set the [Fix Version/s]{.jbs-field} to the exact release the backport is targeting, but in general this isn't recommended unless you are targeting a feature release in ramp down. When a change is integrated to an update release repository, the bots will look at the main issue as indicated in the PR title, and look for backports with the current `N.0.x` release version as [Fix Version/s]{.jbs-field}, if no such backport is found they will look for `N-pool`, and if that isn't found either, a new backport issue will be created. This means that if the backport has an exact [Fix Version/s]{.jbs-field} set, but is delayed and misses the release indicated by this [Fix Version/s]{.jbs-field}, a new backport issue is created with a small mess as the result. (See [How to fix an incorrect backport creation in JBS].)
> 
> Maybe "a new backport issue is created" -> "a new, superfluous backport issue is created".  I think "superfluous is correct as that issue will be closed per the instructions in [How to fix an incorrect backport creation in JBS].

Agreed. Fixed.

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

PR Review Comment: https://git.openjdk.org/guide/pull/129#discussion_r1656933461