[Proposal] Maintainer Approvals and SKARA

[Andrew Hughes]

On 07:01 Thu 24 Mar     , erik.joelsson at oracle.com wrote:
> Hello,
> 
> I agree that solving SKARA-1199 would provide quite a bit of benefit to 
> the update releases. The current process works, but it requires 
> knowledge and manual care to not make mistakes. One of the main ideas 
> with Skara was to codify our processes to make them more foolproof and 
> easy to follow. I definitely think this approval process fits the bill 
> as something we should support better with tooling.
>

I completely agree with this and it's one of the things I like about
switching to using SKARA.

> Breaking apart the problem a bit, from the perspective of a user 
> developing a fix for an update release that requires approval, I agree 
> with Kevin that the current state of the approval should be reflected as 
> a "progress" on the PR. That makes it very clear if the PR is ready for 
> integration or not and fits in with how Skara tracks and treats other 
> integration blockers. Basing this functionality around the model of the 
> /sponsor command would be a pretty major shift in my opinion. It moves 
> the ability to actually integrate, and as such the control of the 
> timing, from the contributor to the integrator. This mimics how some 
> other big open source projects handle things (e.g. the Linux kernel). I 
> think it makes sense to do this when sponsoring, because we are then 
> helping new and inexperienced (in OpenJDK processes at least) users, 
> which helps prevent mistakes. For contributors of committer status or 
> above, I think we should retain their ability to control the timing of 
> integration. Implementation wise, I don't think it makes a big difference.
>

I have no issue with this at all. I merely used the 'sponsor' example
because it was the most obvious example of something that seemed similar
in the code. As you know the details of SKARA far better than I do, I'm
happy to follow your lead on the best place to implement this.

> The other part of the problem, which I think is what this discussion 
> should really focus on, is where the official approval takes place. We 
> can keep it in JBS like today, or we can move it to the PR, as suggested 
> by Andrew. From an implementation point of view, moving it to the PR is 
> less work, but I don't think we should base this decision on process on 
> if it takes an extra day to implement. The tooling should support the 
> process we want.
>

I'll confess that my initial motivation in rethinking the process was
to see if we could simplify the implementation of this, given it seemed
to have stalled since we first discussed it last year. But, having
taking a step back to analyse what we're doing with approvals and why,
I think there are several other benefits to integrating the process
more into the SKARA way of doing things, which I hopefully outlined
in my initial e-mail.

Probably the main issue is that the JBS method of approval remains
inaccessible for those who aren't OpenJDK authors, and for everyone
when the bug itself is not public (we tend to encounter more of them
in 8u, it seems). Making approvals easier in these cases would
definitely be a benefit.

> Without having spent a lot of time thinking about it so please tell me 
> if I'm missing something, would it be possible to support a hybrid/dual 
> solution? The official process could still be the labels in the JBS 
> issues, but the Skara 'integrator'-only /approve command on a PR could 
> also add the appropriate *-fix-yes label to all associated bugs. There 
> would also be a Skara bot monitoring JBS and automatically updating the 
> approval status on PRs based on labels in JBS. This would shortcut the 
> process for integrators that prefer working through PRs, while 
> integrators that prefer to work through JBS can continue the same way as 
> before. I think this should alleviate the issue of backporting many bugs 
> with one PR. This is of course also the biggest change to implement, but 
> not that much more than what I had already outlined in SKARA-1199.
>

This does sound like an even better option, providing the best of both
worlds as we do with the ability to use SKARA via both the GitHub
website and e-mail.

My main concern is the work involved, but if you are happy to do this,
then I would be very grateful to have this in place and willing to help
out where I can.

> /Erik
> 
> 

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