EPEL/Packagers

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

Workflow

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 whitelisted). There is a known issue that currently collaborators cannot request new branches that we will address.

Automatic branching is also 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.

How can I contribute?

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 for [provenpackagers](https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/#_becoming_provenpackager):

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

Communicating with the EPEL SIG

We use the same communication channels as the main SIG; see Communicating with the EPEL SIG for details.