#101 Policy for stalled EPEL requests
Closed: Fixed 3 years ago by tdawson. Opened 3 years ago by churchyard.

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:

  1. a packager asks for epel package trough BZ, offering their involvement
  2. if there is no negative reply for ??, the packager can get epel ACLs trough a releng/epel ticket

And the ACLs would be granted trough https://pagure.io/pagure/pull-request/4786 and the default bugzilla assignee UI.


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.

Thus far, this is what we have (some details are still missing)

  • A packager opens a bugzilla requesting a package be added to EPEL. They also express that they are willing to help maintain / co-maintain that package in EPEL-X.
  • A period of time goes by
  • They re-say that they are willing to maintain / co-maintain the package in EPEL
    • This is just incase the initial message was missed.
  • A period of time goes by
  • They file a rel-eng ticket, that points to the bugzilla, requesting appropriate privileges to be able to branch and build that package in EPEL-X
  • The privileges are given
  • They then request a branch, and build the package in EPEL-X following normal ways.

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?

  • 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)

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)

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.

  • A packager opens a bugzilla requesting a package be added to EPEL. They also express that they are willing to help maintain / co-maintain that package in EPEL-X.
  • A week goes by with no response
  • They re-say that they are willing to maintain / co-maintain the package in EPEL
    • This is just incase the initial message was missed.
  • A week goes by with no response
  • They file a rel-eng ticket, that points to the bugzilla, requesting appropriate privileges to be able to branch and build that package in EPEL-X
    • Currently that privilege is "admin"
    • This part of the policy will adjust as various features get implemented in pagure and dist-git
  • The privileges are given
  • They then request a branch, and build the package in EPEL-X following normal steps.

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.

What about the default EPEL point of contact?

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

  • The privileges are given and the packager is made the bugzilla contact for EPEL-X

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

  • The privileges are given and the packager is made the bugzilla contact for EPEL.

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.

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.

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.

  • 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.
  • A week goes by with no response
  • They re-say that they are willing to maintain / co-maintain the package in EPEL
    • This is just incase the initial message was missed.
  • A week goes by with no response
  • They file a rel-eng ticket, that points to the bugzilla, requesting appropriate privileges to be able to branch and build that package in EPEL-X
    • This part of the policy will adjust as various features get implemented in pagure and dist-git
  • The privileges are given and the packager is made the bugzilla contact for EPEL.
  • They then request a branch, and build the package in EPEL-X following normal steps.

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...

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)

3 years ago

Login to comment on this ticket.

Metadata