RFR: Section on backporting [v6]

[Jesper Wilhelmsson]

On Wed, 1 Dec 2021 17:58:23 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> 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>
>
> 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.

Thank you for the review. I have included the change and CSR example so resolving this comment. Reply about n-pool in the next comment :-)

> 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.

I don't see why there should be a difference between 8u and later releases. The tooling handle these releases exactly the same way as far as I know. Is there any official communication saying that 8u shouldn't use 8-pool?

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

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