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

[Lindenmaier, Goetz]

Hi,

I can follow what you are saying about the Skara implementation.
I think we can handle the process entirely in PRs, but for me it is
really important that Skara adds relevant information to the 
JBS issue in the end.

One thing I think should not be over emphasized:
> There are some additional benefits to developers, such as removing the
> need for someone to have JBS access to request approval, but the
Backports from people without JBS access should be rare. If they 
do many backports, they can and should get the proper roles to 
have the access.  If they are one-time backporters, the overhead 
for them and sponsors should not be considered.
Instead, we should optimize the administrative process for the 
power users.  Currently, I look at about 20 approvals on a daily 
basis! And there were a lot which were just incomplete where 
I had to check whether they got a review or dependent issues 
were backported over and over again... 
Similar for the backports I do.  The overhead of a 1-line test-only
clean backport is ridiculous!

If it is a backport that is technically demanding, the administrative
part is negligible no matter how the process is set up. For all three
roles, the backporter, the reviewers and the maintainer.
And yes, for such backports I go to the PRs and changes
of the original issue and previous backports to decide on 
the approval.  

For what needs to go to JBS, we should take Java users
into account that see a VM bug in their Java application and check
JBS for a potential fix. They should not have to search 
through the PRs for information.

The information I would like to see in the (main) JBS Bug:
 * The entry in the "Backports" section
 * The link to the commit and the PR in the "Issue Links" section
 * The "Fix request [version]" comment by the backporter
 * Comments by the maintainer telling
    - why it was labeled -fix-no (in case it was rejected)
    - technical concerns why it should be backported or not
      and a reasoning about the decision.
      E.g., I think the decision why we decided to backport
      CGroups 2.0 should be in some JBS issue. Unfortunately 
      it is not.  (I think here we can improve, including myself)

What I think is not important in JBS is 
  * the fix-request and -fix-yes/no labels
     If there is a process enforcing the approval in PRs the 
     fact that the issue is in the "Backports" section (i.e. it was  
     pushed) shows that it was approved.
    (Eventually Skara could put a comment "Fix request approved [version] XY approved the request" 
    Into the JBS issue).
  * The comment saying "A pull request was submitted for review ..."
     This is redundant and the link can be found in the "Issue Links" section.
     I think this just spams the comments.

Best regards,
  Goetz.






> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-retn at openjdk.java.net> On
> Behalf Of Andrew Hughes
> Sent: Wednesday, March 30, 2022 9:26 PM
> To: Kevin Rushforth <kevin.rushforth at oracle.com>
> Cc: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Re: [External] : Re: [Proposal] Maintainer Approvals and SKARA
> 
> On 05:07 Thu 24 Mar     , Kevin Rushforth wrote:
> >
> > > 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
> >
> 
> Ah ok, one of my main motivations behind the change was to reduce the
> work required in SKARA. After reading the code and discussing this with
> Erik, I got the impression that it was easier to implement if the
> process was mostly self-contained within the PR, with SKARA only reaching
> out to JBS to make changes.
> 
> To implement the existing system would require SKARA to be constantly
> polling the referenced bugs to see if someone had added jdk<x>-fix-yes
> to the bug. I believe this is already something that is proving
> problematic with CSRs, where the SKARA PR can become out of sync with
> the CSR bug item.
> 
> There are some additional benefits to developers, such as removing the
> need for someone to have JBS access to request approval, but the
> primary one was to avoid a large amount of SKARA development work if a
> simple change could be made to where the approval process takes place.
> 
> Thanks,
> --
> 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
> 93ffe9f9904a4af1e20008da12833dac%7C42f7676cf455423c82f6dc2d99791af7
> %7C0%7C0%7C637842652152336329%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000&sdata=wbJIiOD%2BGaYoCXOx2trvdjVI2whGQFzVkAJPJ6I9icI%3D&a
> mp;reserved=0)
> 
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222