[Proposal] Maintainer Approvals and SKARA

[Andrew Hughes]

On 14:13 Wed 23 Mar     , Kevin Rushforth wrote:
> Without discussing whether I think this is a better approach than the 
> existing label (it's certainly more work, and requires formalizing the 
> role an "approver" in Skara, but I'll let others comment on the relative 
> merits), I did want to comment on one aspect of your proposal. I don't 
> think that having another state *after* integrate is the best way to go. 
> Even if you don't use the bug database to record approvals, It seems 
> cleaner to make the approval an integration blocker in the same way that 
> the appropriate number of reviews, a matching title for the PR and bug, 
> etc., are integration blockers. That way once Skara says "ready" to 
> integrate, it really is.
> 
> So my recommendation is that, regardless of whether SKARA-1199 is 
> implemented via JBS labels or some other approval mechanism, the 
> "approval" label (or whatever it is called) is added initially when the 
> PR is created, and is an integration blocker. An "approver" can then 
> indicate approval, either in parallel with the review or after the 
> review is done (just like CSR reviews). Once both the review and the 
> approval are done, Skara would mark it as "ready".
> 
> -- Kevin
> 
> 

I don't have a strong issue with doing it that way instead. My initial
suggestion was based on how the sponsorship system works at present,
because this is essentially the same thing - block until someone else
gives the ok - and that is the time in the process when we would
currently approve changes.  For 8u, we've tended to ask people only to
add jdk8u-fix-request when the change has been reviewed and is
"ready".

I don't see how one would approve something that is not in its final
form, but there's certainly no reason to complicate things by making
it impossible to do so.

As to the role of approver, it would be those who are currently
maintainers for the update project. There is already a role in SKARA -
integrators - which I believe fits the bill and is already required to
tag commits and perform merges.

I'm not sure how you see this as "more work", as the existing task
of flagging the issue for approval would now be handled by the bot,
rather than the committer.

Thanks,
-- 
Andrew :)
Pronouns: he / him or they / them
Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222