Proposing an EPEL packaging SIG

[Michel Alexandre Salim]

Hello all,

Following up from last week's EPEL Steering Committee meeting, I'm
presenting a proposal to create a dedicated SIG to make it easier to
get Fedora packages into EPEL and keep them maintained.

Using the Fedora Changes Process template for this to help structure
the proposal, though this is not really a Fedora Change.

== Summary ==

Have a dedicated SIG for packagers who are interested in making more
Fedora packages available for EPEL releases.

== Owner ==
* Name: [[User:salimma|Michel Salim]]
* Email: <michel(a)michel-slm.name&gt;

== Detailed Description ==

RHEL/CentOS releases are branched off from Fedora; since RHEL 8 this
happens every 3 years. Only a subset of Fedora packages get shipped as
part of RHEL, as Red Hat provides support on these packages for their
paying customers; EPEL (Extra Packages for Enterprise Linux) fills in
the gap; this is similar to the old split between Fedora Core and
Extras.

EPEL packages are maintained in dist-git as additional branches on
Fedora packages; however, unlike with Fedora releases, where by default
a package gets branched for any new Fedora release, EPEL branches are
only created if one of the package maintainers request it (it's opt-
in).

The rationale is that many Fedora packagers do not specifically care
about EL, and with their long release cycles the maintenance burden is
higher (e.g. upgrading to fix a security vulnerability might not be
possible if the newer fixed version has unmet dependencies, so
backporting the fix might be required). EL is more often used server
side too, so the average Fedora packager is not expected to be an EL
user.

This poses a problem for those of us who rely on packages in EPEL --
e.g. Fedora Infrastructure, and many corporate deployments. Right now
the process is as such:

* An org starts rolling out the new version of EL
* It turns out a given package is not available in EPEL
* Bug filed requesting that package be branched and built
* Worst case scenario, no response and we need to use the non-
responsive maintainer flow
* That package might have other unmet dependencies, so repeat this
cycle several times
* Wait for each of these packages to go through the update system
* For organizations that have their own internal mirrors, they now need
to sync the new packages

There are several changes we can make to both streamline the process,
and not increase the maintenance burden on the (other) maintainers of
these packages:

* Have an EPEL SIG modeled after the SIGs centered around programming
language stacks (e.g. Python, Haskell, Java)
* Have an expedited flow where this SIG can request EPEL branches and
admin access to packages if there are no response from package
maintainers for a set period (3 days? 1 week?)
  * whether it should be full admin access or whether such access
should be scoped to epel* branches can be discussed. Full admin would
make it possible to adjust the spec in Rawhide to be more EPEL
friendly, for example
* Members of the EPEL SIG can then branch these packages early when the
next EL release is branched
* The member of the SIG doing the branching should be designated as the
primary EPEL assignee for that package

One deviation we might want to have from how Python SIG works is... we
probably don't want to encourage packagers to add this EPEL SIG as a
comaintainer preemptively, but only as needed.

== Benefit to Fedora ==
=== Smoother infra upgrades ===
Upgrading the Fedora infrastructure will get easier over time, as more
of the necessary EPEL packages become co-maintained by the EPEL SIG,
which reduces the amount of time needed to get these packages available
on new releases.

=== Packager experience ===
Reduced burden on Fedora package maintainers who are not interested in
EPEL - the choice is now either:
* One of the existing maintainers does the work of branching and
building
* The requestee gets added as a maintainer and does it
* The request stalls because the requestee is not a packager

=== More involvement by CentOS-using organizations ===
With the EPEL SIG, we should encourage organizations with a long-term
need for EPEL to get their members / employees added to this SIG, so
scenarios #2 and #3 basically becomes this:

* EPEL SIG gets added as co-maintainer of this package

This might encourage more contributions from companies that
traditionally just consume RHEL/CentOS + EPEL, and as RHEL/CentOS is
increasingly developed in the open with CentOS-Stream, eventually also
make it easier to get these companies' input into the EL development
process.

== Scope ==

* Proposal Owners
  * Ask Infra to set up EPEL SIG ACL and mailing list (for Bugzilla)
  * Announce this in epel-devel
  * Have documentation for the SIG as part of the EPEL documentation
  * Help onboard people to this SIG

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/[e-mail]
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2