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

[Erik Joelsson]

On Fri, 23 Sep 2022 12:58:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ah, I see. Maybe `needs-approval` then?
>
> Or maybe I need to understand the entire labeling workflow better... 
> 
> Is this label supposed to signal "this PR is of a kind that needs approval" and all PRs of that kind (i.e., it is a backport made to an update repo) will have that label during their entire life span? Or is it supposed to act like a release blocker (as `ready` but inverted), so when approval is given, then the label is dropped?
> 
> I have a hard time figuring out how this PR label relates to the "important" labels in JBS. I think I naively assumed that the PR label should reflect the state of the JBS labels, so you could understand from looking at the PR (and not having to go to JBS) to understand if it was in a state where it needed an approval request in JBS, a JBS approval request had been asked, or an approval had been given or denied in JBS. 
> 
> Since that was my mental model, having just a single `approval` label made no sense at all to me.

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.

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

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