On Fri, Sep 11, 2020 at 11:52:03AM -0700, Michel Alexandre Salim wrote:
...snip...
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.
I'll add that in addtion to some maintainers not wanting to maintain
their fedora packages also in epel, the timelines involved sometimes
make it so a package that was branched/maintained in epelX, makes no
sense in epelY. ie, Xfce 4.14 would be fine now, but in 3 years, 4.16 or
whatever would make more sense and the package set may well not be the
same.
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
I wonder... could we somehow let maintainers indicate "I want my package
branched for the next epel as soon as it's available"? I suppose in part
thats what adding epel-sig would do? With the addition of 'epel-sig
should build by packages as soon as those branches are ready'.
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?)
Both of those are really short... I guess a week or two might be ok.
* 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
How would that be designated?
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.
That would defeat the purpose of using epel-sig packages as 'always
branch' wouldn't it?
The other hazard if that different maintainers have different workflows
and epel-sig folks would need to adjust to those. ie, some people want
master to have epel conditionals and merge back to epel branches, some
don't want that at all. I wonder if it wouldn't make sense to have some
way to indicate to people what workflow is in effect for the package (I
guess spec file comments?)
kevin