#10141 Improve the SCM request process to let the current maintainers confirm the EPEL branches.
Closed: Can't Fix 2 years ago by humaton. Opened 2 years ago by vondruch.

Tickets like https://pagure.io/releng/fedora-scm-requests/issue/34345 are closed as invalid without the maintainers being asked. This is unnecessarily cumbersome. If I was at least able to reopen the ticket, but I am not. Please make the process easier especially for EPEL branches.


I think the ticket should actually pass, because I've added the requester to collaborator of the package - with privilleges on epel*,el* branches.

@vondruch well, I think the message is clear. You have to make the requester maintainer of the package. When that is done the requester can reopen the ticket or create a new one.

@vondruch well, I think the message is clear. You have to make the requester maintainer of the package. When that is done the requester can reopen the ticket or create a new one.

@humaton does collaborator count as a maintainer? I've mistakenly set the filed to 'el*' branches only (it there as an example in the webUI) at first, so that might have caused this issue.

Honestly, I'd like to be able to give blanket approval to whoever request the EPEL branches without me even noticing. That is what I really want.

If I need to be involved, then giving approval in the SCM request seems to be the easiest approach.

The least friendly approach is to give some privileges in the pagure UI.

Currently, the communication typically looks like receiving email or ticket, me having to respond. Then figuring out what is the process needed to do thing I don't really care about, etc. This is disservice to current maintainers as well as the prospective EPEL maintainers.

@humaton does collaborator count as a maintainer? I've mistakenly set the filed to 'el*' branches only (it there as an example in the webUI) at first, so that might have caused this issue.

Yes, it should.

@vondruch so we can process the tickets without checking if the requester has access or is a member of groups that have commit access. I can make that a default option.

@humaton does collaborator count as a maintainer? I've mistakenly set the filed to 'el*' branches only (it there as an example in the webUI) at first, so that might have caused this issue.

Yes, it should.

Great! My mistake, then. Sorry.

@vondruch so we can process the tickets without checking if the requester has access or is a member of groups that have commit access. I can make that a default option.

Is that a general rule, or per-person? Could you add me as well?

But we still need to add users as collaborators, right?

If they're a member of the epel-packager-sig, then no. Otherwise, yes. The epel-packager-sig is essentially equivalent to provenpackager + new branch power for EPEL branches.

so we can process the tickets without checking if the requester has access or is a member of groups that have commit access

Please don't do that. While it might work for @vondruch, it does not work for all package maintainers. I for example don't want epel branches to be created without an assigned epel maintainer.

If they're a member of the epel-packager-sig, then no. Otherwise, yes. The epel-packager-sig is essentially equivalent to provenpackager + new branch power for EPEL branches.

Also, please don't. If epel-packager-sig wants to maintain a package in epel, they need to be assigned as maintainers first. This has been discussed several times already in different tickets/email threads.

I suspect what @vondruch actually wants here is to say "yes, anybody can request an epel branch in packages I maintain in Fedora" but that should also have "assuming they take responsibility of that package in epel".

so we can process the tickets without checking if the requester has access or is a member of groups that have commit access

Please don't do that. While it might work for @vondruch, it does not work for all package maintainers. I for example don't want epel branches to be created without an assigned epel maintainer.

If they're a member of the epel-packager-sig, then no. Otherwise, yes. The epel-packager-sig is essentially equivalent to provenpackager + new branch power for EPEL branches.

Also, please don't. If epel-packager-sig wants to maintain a package in epel, they need to be assigned as maintainers first. This has been discussed several times already in different tickets/email threads.

Sure, but the SCM request should auto-assign them maintainership for that branch.

Sure, but the SCM request should auto-assign them maintainership for that branch.

Yes, that might work, assuming https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Stalled_EPEL_Requests is replaced with "anybody can request an epel branch and they will automatically get it" (that works for me, but I assume it does not work for everybody).

BTW here is some context: https://pagure.io/releng/issue/9068 https://pagure.io/releng/issue/8844

I suspect what @vondruch actually wants here is to say "yes, anybody can request an epel branch in packages I maintain in Fedora" but that should also have "assuming they take responsibility of that package in epel".

That is correct

Sure, but the SCM request should auto-assign them maintainership for that branch.

That is what I assume. It event did not come to my mind that somebody would request EPEL branch but I would be assigned as a maintainer.

Nevertheless, the current JSON scm request does not have a field for that, so my assumption could have been naive.

Metadata Update from @mohanboddu:
- Issue tagged with: medium-gain, medium-trouble, ops

2 years ago

@vondruch closing this as won't fix. If you want to make changes in the epel workflow, please open a ticket with the epel project https://pagure.io/epel

Metadata Update from @humaton:
- Issue close_status updated to: Can't Fix
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog