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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
