[Proposal] Maintainer Approvals and SKARA

Thu Mar 24 14:41:52 UTC 2022

+1 !  The information must go to JBS!

... this just came in while I was typing. 

I think it can be achieved by Skara that the right information
ends up in the bug, see my mail on this topic.

> In general, the
> process is fairly well understood and I don't anticipate this to be a
> huge problem in practise.
Incomplete changes being tagged cause 
of overhead on my side (as maintainer).  I read them every day and
check whether the missing parts were added, this
really is a nuisance.

On the other side, needing review and approval sequentially 
causes unnecessary overhead if I am backporting. 

So Skara could help here.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Severin Gehwolf
> Sent: Thursday, March 24, 2022 2:06 PM
> To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: [Proposal] Maintainer Approvals and SKARA
> 
> 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/845d40ae217ff47ec53e2fd655b9
> 593=
> > 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.
> (https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww
> .redhat.com%2F&data=04%7C01%7Cgoetz.lindenmaier%40sap.com%7C
> 66d9ee8f7f544393a57208da0d971909%7C42f7676cf455423c82f6dc2d99791af7
> %7C0%7C0%7C637837239853649848%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000&sdata=uoNga%2FeHXVQ9s9eIUUhU6InC4P4i9fRlv%2F5YGGRKJcE%
> 3D&reserved=0)
> >
> > PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> > Fingerprint =3D 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> >
> > --X28JfW0BSfKBk7hD--
> >