[External] : Re: [Proposal] Maintainer Approvals and SKARA

[Kevin Rushforth]

> 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.

I meant more work in Skara to develop and implement this new feature 
(although Erik could confirm whether my assessment is accurate). I can 
see some advantages for the maintainers, but we need to balance to 
potential benefit against the cost to implement.

-- Kevin


On 3/23/2022 6:21 PM, Andrew Hughes wrote:
> 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,