<div dir="ltr">Hi all,<div><br></div><div>I re-read your comments about this enhancement recently.</div><div>And I also made a mistake when I backport a patch to</div><div>jdk11u-dev [1] although I have backported several times.</div><div>So SKARA must direct the developers accurately and help </div><div>developers complete the duplicated work to avoid the unnecessary mistakes.</div><div><br></div><div>Now I propose the following dev flow. Please only focus on the dev</div><div>flow instead of the code implementation here.</div><div><br></div><div><b>- When a backport PR is created in Github.</b></div><div>1. A new checkbox item `[ ] Change must be properly approved by the maintainers` </div><div>will be added to the `Progress` part of the current PR body.</div><div>2. A comment is posted by the bot like below (the italic content) to direct the developers:</div><div><i>This is a backport pull request. Please add a comment to the main issue [JDK-XXXX](link)<br></i></div><div><i>to state the related condition (the backport reason, the risk of the patch, the amount of</i></div><div><i>work and so on). Below is an example for you:</i></div><div><i>```</i></div><div><i>Fix Request(jdk17u-dev)</i></div><div><i>The code applies cleanly and the test in this change fails without the patch and succeeds after applying it.</i></div><div><i>The risk of this backport is low because the change is little and the issue fixed by this change also exists in jdk xy.</i></div><div><i>```</i></div><div><i>If you don't have permission to add a comment in JBS. Please use the command `request-approval` to provide</i></div><div><i>the related content, then the bot can help you add a comment by using the content you provided. Below is an example for you:</i></div><div><i>```</i></div><div><i>/request-approval</i></div><div><div><i>Fix Request(jdk17u-dev)</i></div><div><i>The code applies cleanly and the test in this change fails without the patch and succeeds after applying it.</i></div><div><i>The risk of this backport is low because the change is little and the issue fixed by this change also exists in jdk xy.</i></div></div><div><i>```</i></div><div><i>Please note you have to contact the maintainers </i><i>directly </i><i>in the issue [JDK-XXXX](link)</i><i> </i></div><div><i>or by using the command </i><i>`request-approval` </i><i>repeatedly</i><i> instead of in this pull request.</i></div><div><i>And you don't need to add the fix request label manually to the issue like before,</i></div><div><i>now the bot can help you add the label automatically when this pull request is ready </i><i>for maintainers to approve.</i></div><div><br></div><div><b>- When the backport PR is ready for approval </b>(other checks have succeeded and other progresses have been done)</div><div>1. The bot adds a label named `jdkXXu-fix-request` to <b>all the issues</b> of the PR</div><div>2. The bot adds a blocked label named `approval` in PR, like `csr` or other blocked labels</div><div>These two labels are convenient for maintainers to filter the issues and PRs which need to be handled now.</div><div><br></div><div><b>- It is time for maintainers to approve</b></div><div>The maintainers can add the label `jdkXXu-fix-yes` or `jdkXXu-fix-no` in the issue or use the command </div><div>`/approval yes|no|y|n` in the PR to approve or object the patch. This newly added command `approval` </div><div>can be very convenient if one backport PR has many corresponding issues. After using this command,</div><div>the bot will add the related label to <b>all the issues</b> just like the label `jdkXXu-fix-request` it had added.</div><div><br></div><div><b>- Then the commit or sponsor flow will continue as usual.</b></div><div>After approval, if the maintainer said 'yes', the PR will become ready to be integrated.</div><div>If the maintainer said 'no', the PR can be closed by the bot with a comment like</div><div>"The maintainers disapproved of this patch so this pull request will be closed automatically".</div><div>No matter 'yes' or 'no', the label `approval` in the PR will be removed.</div><div><br></div><div>Above is all the dev flow. And next, I will give more information about the new commands `<b>request-approval` and `approval`.</b><br></div><div><br></div><div><b>- "request-approval" command</b></div><div>It is similar to the `summary` command which permits multiline content. And this command can be used </div><div>multi times if the author of the PR wants to. Each time this command is used, the bot will post the content </div><div>to a new comment in the issue. Because the author who has no permission may want to contact/talk with the maintainers.</div><div>The related record will be recorded in the issue instead of PR which is your intention in your previous comments.</div><div><br></div><div><b>- "approval" command</b></div><div>The command `/approval yes` or `/approval y` mean `approved`.</div><div>And the command `/approval no` or `/approval n` mean `dispproved`.</div><div>This command can be used multiple times and only the last time is valid.</div><div>Please note when the `/approval no` or `/approval n` is used, the bot will close the PR,</div><div>and when the `/approval yes` or `/approval y` later is used, the bot will open the PR automatically.</div><div><br></div><div><br></div><div>That is all. Thanks for reading and providing feedback. </div><div>And I will try to implement these features if I have time and hear no objection after discussion.</div><div><br></div><div>[1] <a href="https://github.com/openjdk/jdk11u-dev/pull/1218#issuecomment-1184235601" target="_blank">https://github.com/openjdk/jdk11u-dev/pull/1218#issuecomment-1184235601</a></div><div><br></div><div>Best Regards,</div><div>-- Guoxiong</div></div>