RFR: 1797: Add support for /backport pull request command

[Erik Duveblad]

> On 3 Feb 2023, at 03:09, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 3/02/2023 11:48 am, David Holmes wrote:
>> On 2/02/2023 9:33 pm, Erik Duveblad wrote:
>>> 
>>> A user can already today type `/backport` in a commit comment for
>>> the commit a pull request resulted in once it was integrated. This can be
>>> done only seconds after the pull request was integrated and the Skara
>>> bots will then go ahead and create a “backport pull request” (see the
>>> Skara wiki on backports for more details [0]). Zhao’s patch only removes
>>> the manual step of having to navigate to the GitHub page for the
>>> resulting commit and add a commit comment. With Zhao’s patch a user can
>>> now instead type `/backport` in the pull request and the Skara bots will
>>> create the “backport pull request” once the pull request has been
>>> integrated.
>> Sure. And I understand better this isn't really trying to allow (though it does) the ability to type:
>> /integrate
>> /backport ...
>> in a PR but more dealing with the common(?) problem that when someone does decide to backport a change they tend to go to the JBS issue, see the PR link, go to the PR and type "/backport ..." only to be told they are in the wrong place and need to go to the commit. I know I've done it myself :)
> 
> Though that said, there really isn't any motivating usecase I can see for allowing /backport in an open PR.

I agree with what Erik J wrote on this and see three primary motivations:

1. You signal to reviewers of the PR that you intend to backport this PR. This can be useful information to the people reviewing the change in the openjdk/jdk repository. It can also be a useful heads up to the maintainers of the repository you intend to backport to, many of those maintainers are also following pull requests targeting openjdk/jdk:master.

2. It is convenient if I _know_ already when creating the PR in the first place that I will backport this later. I can just add the `/backport` command in the PR body, let the reviews process run its course, let the resulting commit soak for a while. Then I can come back to the PR (for example via the link in the JBS issue) and just click the link that the bots have already prepared for me.

3. In the case of 2), some contributors might actually prefer to create the “backport pull request” early, as a way to remember to complete the backport at some time in the future (the “backport pull request” will be assigned to your GitHub user). Such contributors must of course do as Thomas wrote and update their “backport pull request” with the latest changes before integration, but it is still a scenario I think we should support. Creating a “backport pull request” somewhat early is also yet another signal to maintainers of that release that “this is coming”, even though it is not ready just yet.

I personally think the three motivations outlined above is more than enough to support `/backport` in an open pull request, primarily as I can’t see any drawbacks. The only drawback I can imagine would be “trigger happy” contributors who might backport right away, but as I wrote earlier, that “problem” (which we’ve never run into AFAIK) can already happen today: a user just have to add the `/backport` _commit_ command to the commit the PR resulted in as soon as it has been created.

Thanks,
Erik