Allow epel-packagers-sig members to request `epel*-next` branches on any EPEL package

Project Discussion
1

I first brought this up in the EPEL issue tracker, but I’m cross posting it here for community discussion.

https://pagure.io/epel/issue/263

Currently when a packager requests a new branch for a package, the RelEng tooling is set up to allow the request in the following scenarios:

  • the requestor is an admin (or in a group that has admin) on the package
  • the requestor has commit (or in a group that has commit) permission on the package
  • the requestor has collaborator (or in a group that has collaborator) permission on the package via a branch matching pattern

We intentionally don’t allow members of the provenpackager group to request epel* branches to avoid maintainers feeling like they’re forced to maintain EPEL packages.

However, there is a special scenario that needs further consideration: a package already has an epel* branch but needs a corresponding epel*-next branch. In theory the existence of the epel* branch means that an admin, committer, or collaborator has already agreed to maintain the package in EPEL. I think we should allow members of the epel-packagers-sig to request epel*-next branches on any package that already has the corresponding epel* branch (i.e. epel9-next when epel9 exists). I’ve seen instances where a bug is reported for an EPEL package that doesn’t install on CentOS Stream, meaning an EPEL Next build is needed, but the maintainer is unresponsive or doesn’t understand the problem. This results in an unnecessary delay in fixing the installability bug. I think we should allow this via the RelEng tooling, and create an EPEL policy similar to the proven packager policy that states epel-packagers-sig members should try to communicate with package maintainers before taking action.

If anyone reading this needs clarification on when an epel*-next branch is needed, please refer to the docs.

5 Likes
2

Is there another change needed so they can also build and submit an update, in this case? IIRC that normally requires provenpackager

3

This all sounds pretty reasonable to me.

kevin

4

That’s something further we could discuss further, although I’m not sure what it would look like in the end. When creating the EPEL Packagers SIG we talked about having it work somewhat like “provenpackager for EPEL”. This proposed policy is a step in that direction, but doesn’t go as far as allowing EPEL Packager SIG members to create builds and submit updates. But it does let them request the branch that they can then send a pull request to, getting the process further along. That state would make the intended solution more clear to maintainers, get the results of a CI run, and make it easier for maintainers or provenpackagers to merge the change.

5

this seems reasonable, as discussed in last week’s meeting

6

https://pagure.io/epel/issue/263#comment-888013