Re: [EPEL-devel] Proposing an EPEL packaging SIG

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux