[Proposal] Maintainer Approvals and SKARA

Thu Mar 24 13:05:43 UTC 2022

On Wed, 2022-03-23 at 20:13 +0000, Andrew Hughes wrote:
> 
> Hi all,
> 
> We have been discussing how to implement and/or adapt the current
> approval process (jdk<x>-fix-request, jdk<x>-fix-yes, etc.) to SKARA
> on this bug: https://bugs.openjdk.java.net/browse/SKARA-1199
> 
> At present, we have been continuing to approve bugs for update
> releases as we did in Mercurial; when the change is reviewed, the
> proposer should flag it as jdk<>-fix-request (or
> jdk<>-critical-request for a rampdown fix) and then an approver
> responds with the *-yes or *-no response on the bug.
> 
> SKARA has introduced a new worry for me into this process, due to the
> way the PR bot directs the user through the change process. This in
> itself is a good thing. However, while it is currently not aware of
> the approval process, it can encourage someone to integrate a change
> which has not yet been approved. Hence why I feel some solution to
> SKARA-1199 is quite critical (especially with the potential move of
> the master 8u repository to SKARA) and it surprises me that other
> update projects have not pushed harder for this, prior to 8u adopting
> SKARA.
> 
> In thinking through how to implement this in SKARA, it occurred to me
> that trying to continue with what we have now may not be the best
> solution. The issues I see are:
> 
> 1. Having the approval process in the bug database separate from the
> proposed commit on GitHub creates a disconnect between the two.
> We had this before, with the separation between mailing list activity
> and the bug database, but now that pretty much everything else
> happens in GitHub/SKARA, it feels odd to have to go back and forth
> between JBS and GitHub to approve a change.

> 2. Access to add a label in JBS requires someone to have JDK
> authorship
> status, so, for non-authors, someone else has to do this on their
> behalf (as with sponsoring)
> 
> 3. On the flip-side to #2, any JDK author can add jdk<x>-fix-yes or
> jdk<x>-critical-yes to a bug, as I believe has happened in the past.
> 
> 4. From a technical perspective, this means JBS has to be regularly
> probed to pick up new labels. This also affects CSRs, which already
> have issues in this area, and the demand for backports would be
> much higher.
> 
> 5. When we've dealt with backports which affect multiple bugs,
> the informal process we've had in the past means we've been able
> to choose whether to require that all bugs are flagged or not.
> Having a formal version of the process we have now in SKARA would
> mean having to label every referenced bug in something like [0].
> 
> My proposal would be that we shift approvals to SKARA in a similar
> way to which sponsorship is currently handled:
> 
> 1. When a PR for a backport project reaches the point at which
> it would currently be integrated (after either /integrate for
> a committer or /sponsor for a non-committer), it instead
> gets an 'approval' label.
> 
> 2. For the PR to move forward, an 'integrator' (someone capable
> of merges & tags) [1] would need to perform '/approval [yes|no]' to
> cause the change to either be integrated or rejected.
> 
> I believe this would simplify the implementation of this feature
> a lot and also integrate it better into SKARA.
> 
> The bot could still label bugs with the jdk<x>-fix-request when
> it adds the 'approval' label to the PR and with jdk<x>-fix-yes
> and jdk<x>-fix-no when the /approval command is used.
> 
> The use of jdk<x>-fix-request or jdk<x>-critical-request can
> also be pre-determined by the bot, based on the repository
> the PR is against (jdk<x>u-dev for the former, jdk<x>u for the
> latter).  This is something that would go in the server-side
> bot configuration.
> 
> Thoughts?

My worry would be that "Fix Request" comments would be spread across
different PRs if a single bug gets backported to, many update releases.
JDK 18u, 17u, 11u and 8u, for example. It would move the "approval"
conversation to the source control system (and per backport PR) rather
than the bug database. From a maintenance perspective it makes sense to
have all the info related to backports in one place (on the bug). If
something gets requested for 8u, say, I can see immediately in the bug
database that it has been backported to later releases too and can see
the approval flags (and who approved it). Moving this to skare makes
the info much more dispersed.

Besides, we've had the issue of update project committers being able to
integrate without formal approval in JBS before. It's only much more
visible now (which is a good thing). I.e. the problem doesn't change
with Skara. The difference really is bot guidance. In general, the
process is fairly well understood and I don't anticipate this to be a
huge problem in practise.

Thanks,
Severin

> I'm honestly struggling to see why we'd hold onto the existing
> process, but I also realise that adaptation can be hard, particularly
> for other update projects where SKARA has been in use longer.
> 
> [0]
> https://github.com/openjdk/jdk8u/commit/845d40ae217ff47ec53e2fd655b9593=
> 3aa35eac6
> [1] https://bugs.openjdk.java.net/browse/SKARA-1384
> 
> Thanks,
> --=20
> 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 =3D 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> 
> --X28JfW0BSfKBk7hD--
> 