https://koji.fedoraproject.org/koji/builds?userID=ajax&order=-build_id

I'll say first that I know @ajax can absolutely be trusted with provenpackager access.

That said, our (not always adequately followed) policy around granting provenpackager access generally requires that the applicant provide a justification for why they specifically need that level of power vs. just sending merge requests or requesting to be a comaintainer.

@ajax Is there a specific reason to need general access to all packages? Some historical examples include:

• "I'm converting dozens of packages to use updated Fedora macros"
• "I'm working to enable a new CPU architecture"
• "I maintain a commonly-used library and regularly rebuild all the packages that depend on it when it bumps soname".

Note that the pull request in question has now already been merged by the package maintainer.

I'm +1 here since @ajax was already a provenpackager for ages and perhaps we should have a 'returning provenpackager' process like we do for packagers that are dropped from the group for inactivity.

Sent to sponsors for comment/feedback.

I mean... like I said, I've been away for a minute. If merge requests work quickly and reliably across packages - possibly because someone who still has provenpackager is regularly scanning packages for minor MRs - then no I don't need it. Historically much of what I used it for was drive-by ABI rebuilds for soname bumps, simply because I liked being able to use rawhide. But again, if side-tags are sufficiently automatic these days then that's probably not a problem either. Obviously it's easier to skip that bit of process but no I don't strictly need to.

What I'm working on, these days, is compute acceleration. We take Mesa as the core of our support base, but building out and up from there we find many packages that need to make possibly opinionated decisions about which APIs they support and how we package that support, and many of these packages are under active upstream development. The possibility exists - though again, unlikely, and certainly manageable if I simply had enough access to specific packages - that a packaging shift would require changing enough things at once to be impractical without superhero powers. Conversely, we may want to demo some pre-release development (as we've done in the graphics space for Mesa and KMS and so on) and doing so may require touching many things.

I would in principle be fine with simply asking every group for membership and every individually-maintained package for commit access, but I don't see a way to do either thing without sending an email. I would think, as a logged-in user to {accounts,src}.fedoraproject.org, that there would be a button I could click to send that email for me; I could swear there used to be one.

I would also note that accounts and src do not report the same membership list for that group; src is a stale list, I suspect? I don't know if that affects the actual ACL in an undesired way but it would be good to sort that out as well.

I would in principle be fine with simply asking every group for membership and every individually-maintained package for commit access, but I don't see a way to do either thing without sending an email. I would think, as a logged-in user to {accounts,src}.fedoraproject.org, that there would be a button I could click to send that email for me; I could swear there used to be one.

Yeah, back in the old pkgdb days there was a request there, no longer in the newer setup.

I would also note that accounts and src do not report the same membership list for that group; src is a stale list, I suspect? I don't know if that affects the actual ACL in an undesired way but it would be good to sort that out as well.

src.fedoraproject.org / pagure refreshes group membership on login. If someone was removed from the group but never logged in again, it would still show them as being in the group.
We have been working on a automated process to clean up that group membership: https://pagure.io/fedora-infra/toddlers/pull-request/366 hopefully deployed soon.

+1 for the request, and I am adding this to the meeting list so we can discuss Kevin's idea about "returning provenpackager process"

+1

Welcome back to the packaging circus. :smiley:

Given that we have systemic unfixable problems that force the need for provenpackagers, I don't see any real reason to push back hard on this request, given he was a provenpackager before.

From my point of view, he's gravy for it. +1

Approved <+4,0,0>