RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6]

Magnus Ihse Bursie ihse at openjdk.org
Fri Sep 23 14:27:24 UTC 2022

On Fri, 23 Sep 2022 14:22:46 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> My Interpretation of this label is that it gets added when the PR is entering the request for approval stage and gets removed once approval has been given. That doesn't exactly correspond to any of the JBS labels. The approval process starts when a PR is otherwise ready for integration. This label would then automatically show up to remind the committer that approval is needed. It is then the responsibility of the committer to apply for approval in JBS (either directly or through the new `/request-approval` command). The maintainer then approves (in JBS or with the `/approve` command), and once that is done, the PR is truly ready for integration and the `approval` label is removed.
>> Alternative definitions would be:
>> 1. Add it to all PRs that need approval for the whole lifecycle. Not really helpful as this is a per repo/branch configuration option. This would also kind of encourage people to try to start the approval process ahead of time.
>> 2. Mimic the JBS label jdkXu-fix-request. That would make it more useful for maintainers looking for PRs to approve, but would not help remind committers that they need to work on the process. Also I don't think Skara should just copy labels from JBS to PRs. 
>> Similar labels today are `csr` and `jep`. They are added once it's known to Skara that they are needed, either by explicit command or automatic discovery. The `csr` label is removed when that requirement is fulfilled.
> Ok, fine, if the label is `csr` and not `csr-needed`, then it makes sense to have this as `approval`, not `approval-needed`.

How does `approval` interplay with `ready`? Can a PR be both `ready` and `approval` at the same time? Or does it go from `rfr` to `approval` to `ready`? Or something else entirely?


PR: https://git.openjdk.org/skara/pull/1364

More information about the skara-dev mailing list