#3360 provenpackager nomination for james
Closed: Rejected 2 months ago by humaton. Opened 2 months ago by james.

I'd like to become a provenpackager. I used to package and then helped package zsh for a year or two. I've packaged a few older packages that aren't in the distribution anymore. I've not built any non-scratch builds for Fedora in the past few years, although I have built a few for CentOS. I am the current FPC chairperson. I personally know a few provenpackagers and have had them do things for me in the past, but with my current job in CLE it would be useful to be an official member.

I've read the Provenpackager policy and I will abide it.


On the one hand, you're definitely qualified as a long-time packager and FPC chairperson.

On the other, you haven't actually cited a specific reason why you'd need provenpackager privileges as opposed to requesting comaintainership or sending merge requests. Could you elaborate on the need for this privilege, please?

FESCo: Please share this request with sponsors.

you haven't actually cited a specific reason why you'd need provenpackager privileges as opposed to requesting comaintainership or sending merge requests. Could you elaborate on the need for this privilege, please?

I don't have anything specific, for the long term like fixing builds for risc or something, but currently it would be helpful dealing with the mass rebuild fallout. Eg.

https://pagure.io/releng/issue/12527
https://pagure.io/releng/issue/12531

I have mailed the sponsors about this request.

+1 from me, james knows packaging very well and would help others out.

I have no specific objection to @james having provenpackager powers, but I do think we need to get out of approving these when there's no specific reason to grant it.

I am with @ngompa on this.

@james has certainly proven they are qualified. However, I don't really understand why they should need to be a provenpackager.

Although I'm sure that @james has enough knowledge and experience, I think proven packager permissions should only be granted in situations where they are needed.

Furthermore, although it is critical to remember that is it thanks to PPs that Fedora has been able to release (mostly) on schedule for the last 20 years, we should re-evaluate the need the (big) number of PPs we do have today (123 as of now), considering that today our spec files live in Pagure, which supports PRs, which was not the case when PPs got introduced.

If I reconstructed correctly the history of Proven packagers, we could find the following steps:

  • Pre-2008: Core and Extra were different repos. Fedora Core permissions were limited to Red Hatters, which had broad privileges on Core.
  • 2008-2010: with the merge of Core and Extra and the development still in CVS, the packagers that had more than 5 packages could get (with an auto-approval process, if I understand correctly) provenpackager privileges
  • 2010-2016: Fedora moved in git on Gitolite in 2010 ProvenPackagers had more clear policies around them. Gitolite did not had a PR feature.
  • 2016: Fedora moved from Gitolite to Pagure. Pagure introduced the ability to open PRs against packages.

I think mixing together the history of the PP and the forges is needed, since PP exists to solve issues that were encountered along the way to ensure the releasability of Fedora.
All of this to say that, imho, with PRs available, the bar for "requiring PP privileges" should be even higher, since many operations that before required PPp, can now be done with PRs.

I don't have anything specific, for the long term like fixing builds for risc or something, but currently it would be helpful dealing with the mass rebuild fallout.

Helping with the mass-rebuild fallout can be handled with merge requests to Pagure, so I don't think that's a sufficient justification. I'm going to vote -1 on those grounds (and those grounds only).

So, first... can we not mix in changing the existing policy here? I don't disagree that we should rework it/adjust it, but I think we should keep processing requests based on the current policy.

Unless we want to stop processing requests until that is done?

We seem in my mind to be somewhat inconsistent when we ask people for the reason they want the access. Sometimes we are very probing, some other times we just say 'sure'. ;(

"It can be handled in PR's" isn't a full story... as sometimes PR's just sit around and a provenpackager may be needed to merge and build it to fix some serious issue.

If I reconstructed correctly the history of Proven packagers, we could find the following steps:

I'm not sure this is fully accurate...

Pre-2008: Core and Extra were different repos. Fedora Core permissions were limited to Red Hatters, which had broad privileges on Core.

I for one have no idea how core permissions were handled. It was all internal to Red Hat (who I didn't work for at that time)

2008-2010: with the merge of Core and Extra and the development still in CVS, the packagers that had more than 5 packages could get (with an auto-approval process, if I understand correctly) provenpackager privileges

They were all added unconditionally to provenpackager at that time, IIRC.

2010-2016: Fedora moved in git on Gitolite in 2010 ProvenPackagers had more clear policies around them. Gitolite did not had a PR feature.
2016: Fedora moved from Gitolite to Pagure. Pagure introduced the ability to open PRs against packages.

Pagure actually used gitolite for a long while...

PR's still need merging.

Anyhow, there I went and started talking about the policy. :(

[The web interface is failing… I'll try by mail. Sorry for any
repetitions if they happen.]

+1. "Dealing with mass rebuild fallout" is a good-enough reason. PRs
and such are useful, but to fix things in a timely manner, even if PRs
are used for review and CI, we still rely on PPs to do merges and
builds, and also rebuild dependent packages.

Marking to be discussed at the meeting due to -1 vote.

17UTC in #meeting:fedoraproject.org matrix room.

Metadata Update from @humaton:
- Issue tagged with: meeting

2 months ago

+1

(I don't necessarily think we need to cap the number of PPs to an arbitrary number, as long as we PPs only use our extra access rights when absolutely necessary. For consistency, though, the policy does need to be very clear on whether new PPs are added based on merit only, or if they're based on merit + need. This is not clear to me from the docs: https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_becoming_provenpackager )

@humaton I'm not sure if you are counting mine as a -1.

Since I'll probably not be in today's meeting, I'd like to clarify that I'm 0 on this.
As Kevin suggested, it is wrong to mix a clarification/potential change of policy with a specific request, and blocking any request until the policy is reviewed probably does not make sense.

My current issue is that @james is asking for this role for his job without a specific task or change in mind that necessitates the privilege:

I personally know a few provenpackagers and have had them do things for me in the past, but with my current job in CLE it would be useful to be an official member.

If there is a concrete need, I'm all for granting it, but the things mentioned (RISC-V and mass build fallout) aren't enough on its own to me. The RISC-V thing would make sense if there's a Change or something officially indicating we're working on supporting RISC-V in Fedora (which is currently not the case). The mass build thing isn't enough without some demonstration of assisting in fixing things identified from the mass build.

On Tue, Feb 11, 2025 at 02:08:15PM +0000, Neal Gompa wrote:

The RISC-V thing would make sense if there's a Change or something officially indicating we're working on supporting RISC-V in Fedora (which is currently not the case). The mass build thing isn't enough without some demonstration of assisting in fixing things identified from the mass build.

We do not have an official change yet, but people are very much
preparing for that. So while it's early for an official announcement,
pp help with the preparations is certainly useful.

This was discussed in today's meeting:

AGREED: provenpackager nomination for james is rejected (+1, 2, -4)

Metadata Update from @humaton:
- Issue close_status updated to: Rejected
- Issue status updated to: Closed (was: Open)

2 months ago

Log in to comment on this ticket.

Metadata