RFR: Section on backporting [v6]

[Andrew John Hughes]

On Thu, 25 Nov 2021 18:17:46 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Guidance on backporting.
>> Also moved "Backing out a change" to the testing section where I believe it fits better. This section is unchanged.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/index.md
>   
>   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>

Changes requested by andrew (no project role).

src/index.md line 1492:

> 1490: In general there is no need to create backport issues in JBS manually. All work that is done in JBS in preparation for a backport (requesting approvals etc) is done in the main issue. The backport issue will be created automatically by the bots when you integrate the change to the source code repository.
> 1491: 
> 1492: There can be cases where it is motivated to create a backport issue before the fix is done. In these cases set the fix version of the backport to `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 is still done in the main issue.

"it is motivated" -> "it is desirable"
An example would be if a CSR needs to be filed.

With regard to the `N-pool` suggestion, this does not work for OpenJDK 8u, so it should be noted that this is only for 11u and later.

src/index.md line 1494:

> 1492: There can be cases where it is motivated to create a backport issue before the fix is done. In these cases set the fix version of the backport to `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 is still done in the main issue.
> 1493: 
> 1494: Obviously it's possible to set the fix version to the exact release the backport is targeting, but this isn't recommended. When a change is pushed, 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, 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 set, but is delayed and misses the release indicated by the fix version, a new backport issue is created with a small mess as the result.

Using the exact release e.g. `openjdk8u322` is the only option with 8u.

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

PR: https://git.openjdk.java.net/guide/pull/66