EPEL Packagers SIG

About

EPEL Packagers SIG is a dist-git group. Being a member of that group allows you to work with packages that have added the epel-packagers-sig group as a collaborator on their packages. You will be able to branch, build and work on those EPEL packages.

You do not need to be a member of the EPEL Packagers SIG to build packages on EPEL.

EPEL Packagers SIG Sponsors are SIG members that are also on the EPEL Steering Committee.

Why

There is often a lag between a new Enterprise Linux release being available, and extra packages being available for it:

That package has to be branched and built
The existing maintainers have to decide if they want to support the latest EPEL or not
Rinse and repeat for every dependency
Then have years of maintenance and updates for that package

Adding the epel-packagers-sig group as a collaborator for a package gives the regular package maintainer(s) more people to maintain it over the years. It can also help get the package into the latest version of EPEL faster.

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.

Packages

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.

Joining 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.

A candidate should be a skilled package maintainer who is experienced in a wide variety of package types and who are familiar with the Fedora packaging guidelines and EPEL package maintainer policies. They should have been packaging with Fedora and/or EPEL for at least a year.

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 Sponsor will send an e-mail to the SIG members, so they are aware about the ticket.
Packagers SIG Sponsors vote in the EPEL ticket.
You must get at least 1 positive votes from SIG Sponsor 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

Look through the general EPEL issues related to packaging and see where you can help.
Look through the EPEL Packagers SIG bug tracker, see if there are any you want to help with.
Look through old epel bugs. Many of them are requesting packages. See if there are any you think should be added to the EPEL Packagers Sig tracker.
Look at the EPEL Packagers SIG dashboard to see if there is anything there you can do.
Look at Will-It-Install and see if there are any packages that will not install that you can help with.

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.

Want to help? Learn how to contribute to Fedora Docs ›