EPEL Packagers SIG

About

EPEL (Extra Packages for Enterprise Linux) 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 of maintainers that are 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 co-maintainers

  • SIG members can request new EPEL branches for packages they co-maintain

  • SIG members can mark packages they co-maintain 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.

How can I contribute?

We are always looking for interested folks to help out! See the main Joining EPEL page for more information on how to join EPEL.

Join the EPEL Packagers 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.

  • 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 Steering Committee will vote (normal EPEL voting mechanism applies).

Get to work

See the guidelines for stalled requests for follow-ups if a branch request has been stale for at least a week.

Communicating with the EPEL Packagers SIG

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