EPEL Packagers SIG
The EPEL (Extra Packages for Enterprise Linux) SIG creates, maintains, and manages a high quality set of additional packages for Enterprise Linux, including, but not limited to, Red Hat Enterprise Linux (RHEL), CentOS and Scientific Linux (SL), Oracle Linux (OL).
This EPEL Packagers SIG is a subset that is primarily focused ensuring the availability of certain packages that users care about, including their stack of dependencies; we basically want to fill the gap caused by the different workflows for Fedora and EPEL:
Fedora packages get automatically branched for every upcoming Fedora release
Fedora package maintainers are expected to support every extant Fedora release, plus the upcoming release branch and the development branch (Rawhide)
Given that EL releases have a much longer lifecycle, there is no requirement that Fedora package maintainers care about EPEL, and no automatic branching:
The set of packages that are relevant might be different for different releases, especially for non-leaf dependencies
It is more difficult to maintain packages across different EPEL releases
EL use cases often diverge from Fedora use cases
This often means there is a lag between a new Enterprise Linux release being available, and extra packages being available for it:
that package has to be branched
if it has not been branched for EPEL before, the existing maintainers have to decide if they want to support EPEL or not
rinse and repeat for every dependency
We aim to be somewhere in between the language-based SIGs (e.g. the Python SIG) and being "provenpackagers for EPEL":
like the language-based SIG, it’s opt in: if a package maintainer would like help maintaining their packages for EPEL, they can add epel-packagers-sig as comaintainers
SIG members can request new EPEL branches for packages they comaintain
SIG members can mark packages they comaintain to be automatically branched for the next EPEL release
Existing maintainers can decide whether to give the SIG commit access (in which case SIG members can also commit to Rawhide and Fedora branches), or only collaborator access (with epel repos allowlisted). Collaborator access is now sufficient to both request branches and push updates.
Automatic branching is not implemented yet.
Candidate packages for onboarding — NEW branch requests over two weeks old. We should consider reviewing this periodically.
Branch requests and/or bug requests that need to be brought into the SIG’s attention should block the EPELPackagersSIG tracker.
See the guidelines for stalled requests for follow-ups if a branch request has been stale for at least a week.
We are always looking for interested folks to help out! See the main SIG’s Joining EPEL page for more information on how to join the EPEL SIG.
Getting added to
epel-packagers-sig grants collective access to all
packages this group has access to, so we do need to be more careful when
adding new contributors to this group. The procedure is similar to that
File a ticket in the EPEL issue tracker indicating why you wish to become a member.
A Packagers SIG member will send an e-mail to the sponsors, so they are aware about the ticket.
Sponsors vote in the EPEL ticket.
You must get at least 1 positive votes from sponsors with no negative votes, over a one week review period, to be approved.
If you haven’t been approved after one week, the EPEL SIG will vote (normal EPEL voting machanism applies).
Issues are tracked in EPEL’s Pagure.
We use the same communication channels as the main SIG; see Communicating with the EPEL SIG for details.