Would it be possible to have a policy that allows people to get ACLs for epel branches if they want to work on the epel package but the maintainer is not responding? That should make it easier than needing to go trough non-responsive maintainer policy.
I imagine something like this:
And the ACLs would be granted trough https://pagure.io/pagure/pull-request/4786 and the default bugzilla assignee UI.
+1
That is a good point. I will bring it up at the EPEL Steering Committee meeting today.
The EPEL Steering Committee will pursue this. We are going to have a discussion on epel-devel mailling list, to figure out the best way to make this better/faster. We will use this ticket when plans have settled.
Thank You.
Thus far, this is what we have (some details are still missing)
There is still three questions with this. 1 - What is the minimum period of time to wait? 2 - Is it a rel-eng ticket? Or something else? 3 - What privilege is given?
1 - What is the minimum period of time to wait?
1+1 weeks? Otherwise going trough the nonresponsive policy is actually faster.
2 - Is it a rel-eng ticket? Or something else?
If there are people following this tracker who are able to do this, I suggest to use this one to relieve releng from even more tickets.
3 - What privilege is given?
This was discussed in the weekly meeting.
1 - What is the minimum period of time to wait? 1+1 weeks? Otherwise going trough the nonresponsive policy is actually faster.
Agreed. 2 weeks. We will also put a note to be aware of long holidays.
2 - Is it a rel-eng ticket? Or something else? If there are people following this tracker who are able to do this, I suggest to use this one to relieve releng from even more tickets.
it was decided that this would be rel-eng tickets. It was discussed using EPEL issues, but decided that would possibly take longer. The rel-eng issues are watched and monitored. The EPEL issues are done by volunteers, only a couple have the correct privileges.
3 - What privilege is given? sufficient enough o request the branch and commit to it and build from it (i.e. "admin" now, "collaborator" once/if the feature is deployed, or something completely different in GitLab) a default EPEL point of contact "privilege" -- the Fedora maintainer is clearly not interested in EPEL (this version of EPEL, but there is not enough granularity for the distinction)
sufficient enough o request the branch and commit to it and build from it (i.e. "admin" now, "collaborator" once/if the feature is deployed, or something completely different in GitLab) a default EPEL point of contact "privilege" -- the Fedora maintainer is clearly not interested in EPEL (this version of EPEL, but there is not enough granularity for the distinction)
Correct, sufficient to request the branch and build.
Currently that is "admin". We will adjust the policy if/when "collaborator" becomes a feature. We will also adjust it to be just for the requested branch when/if pagure is able to give permissions on a per-branch basis.
This is the proposed policy. If people could look through it for any problems, it would be appreciated.
Stalled EPEL Requests There are times that an EPEL / Fedora package maintainer isn't responding to an EPEL package request. If a different packager would like to build and maintain that package in EPEL, these are the steps they take.
What about the default EPEL point of contact?
Also, technically I'd like to see the first point changed to something like:
Anybody opens a bugzilla requesting a package be added to EPEL. A packager (the bugzilla reporter or another person) expresses that they are willing to help maintain / co-maintain that package in EPEL-X.
sufficient enough o request the branch and commit to it and build from it (i.e. "admin" now, "collaborator" once/if the feature is deployed
This is available as of a few days ago, for groups and users.
https://pagure.io/fedscm-admin/pull-request/32
I was able to request an epel8 branch for a package via python-sig commit permissions, and nothing else.
Also, technically I'd like to see the first point changed to something like: Anybody opens a bugzilla requesting a package be added to EPEL. A packager (the bugzilla reporter or another person) expresses that they are willing to help maintain / co-maintain that package in EPEL-X.
Yes, that is exactly what I wanted. I was having a hard time expressing it so left it how it was because every time I tried it was much too wordy. I will change it to be what you said.
Very good point, and also brought up on the mailling list. I was thinking of putting that in the step for when privileges are given. Something like
I don't know if we can do the contact on a per-branch basis. If not we'll have to think about what we'll do if there was already an EPEL contact. Although, if there was already an EPEL contact, and they are the ones not responding, then this whole process still applies. So if that is the case, perhaps change this to
sufficient enough o request the branch and commit to it and build from it (i.e. "admin" now, "collaborator" once/if the feature is deployed This is available as of a few days ago, for groups and users. https://pagure.io/fedscm-admin/pull-request/32 I was able to request an epel8 branch for a package via python-sig commit permissions, and nothing else.
This is available as of a few days ago, for groups and users. https://pagure.io/fedscm-admin/pull-request/32 I was able to request an epel8 branch for a package via python-sig commit permissions, and nothing else.
For groups, yes. But this is more about individual packagers. For that the "collaborator" privilege would be nice. https://pagure.io/pagure/pull-request/4786
I agree the collaborator feature (per-branch ACLs) would be nice. I was just pointing out that since fedscm-admin#32 was merged, admin is no longer needed to request a branch. Branch requests can now be completed with commit level access, individually or through a group. Which is a nice improvement. :grinning:
I believe this is the final draft. I would like to vote on this final draft at this weeks meeting.
Looks good! Thanks.
The passed the EPEL Steering Commitee. I have updated the policy page.
https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Stalled_EPEL_Requests
BTW as @carlgeorge pointed out
Currently that privilege is "admin"
Is now:
Currently that privilege is "commit"
It has to be 'admin' for now in order for the new maintainer to be able to request the epel branches...
https://pagure.io/fedscm-admin/pull-request/32 says commit.
Thank you for everyone's input. The policy has been updated on the wiki and I am closing the issue.
Metadata Update from @tdawson: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.