On Wednesday, August 10, 2022 4:07:29 PM CDT Troy Dawson wrote: > On Sun, Aug 7, 2022 at 12:31 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Sat, Aug 06, 2022 at 10:05:40PM +0200, Maxwell G via epel-devel wrote: > > > We could create an issue tracker for this. Packagers would have to > > > submit a ticket requesting to orphan a certain package's EPEL branch(es) > > > and set the EPEL Bugzilla assignee to "orphan" if they're orphaning all > > > active EPEL branches. epel-devel@ could be CC'd on all issues. Then, we > > > could have a provenpackager in the SIG go through and manually retire > > > the packages that haven't been picked up after six weeks. The later will > > > be difficult if we have a large volume, but I don't expect that. We > > > could script this if necessary or just ask the submitter to do it > > > themself. > > > > > > This doesn't allow picking up packages in a self-service manner, but I > > > don't think that's a huge deal for our case. > > After some discussion in our weekly EPEL Steering Committee meeting > Maxwell's idea seems to lead the way. > Maxwell has setup of pagure repo, to track these orphan issues. > A pagure repo gives us the opportunity to have a nice README that people > can see if they are unsure of the process. > A pagure issue also seems more user friendly than a bugzilla. Both for the > person creating the issue, and for others tracking it. > > https://pagure.io/epel/package-orphan-requests So, I've started working on this. So far, I have a structured issue template, and I've started writing a tool to go through the issues and act on them (creating an announcement, etc. While I had originally wanted to use a Pagure issue tracker, I decided to switch to Gitlab half way through. There were three reasons: * The Pagure API does not allow tagging existing issues. I had planned to liberally use tags to manage the issues. * Gitlab already has a nice Python wrapper (python-gitlab), which is much easier to work with. * It's more future proof, as the state of Pagure in Fedora is a bit up in the air. I really appreciate Pagure, and I wanted to make it work, but I'm trying to be pragmatic. Currently, the plan for identity verification is to make sure the sure the user is a member of the Fedora group on Gitlab. For non-matching usernames, I should be able to provide a dedicated field for that and cross reference the custom username with the FAS Gitlab field. Does anybody know if it's possible to limit issue submissions to only Fedora members while keeping the issue tracker public? That would make this easier. I have one question: who should be able to orphan EPEL branches? In Fedora, it's only the main admin. Do we also want to open this up to people with other privileges? Currently, anybody with any type of write permissions on a repository can retire the package. If the actual people who maintain the EPEL branches don't have permissions to orphan EPEL branches, I worry it will make the policy ineffective. > The policy isn't setup yet, but we are moving in the right direction. Indeed :). -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
