Reading this proposal and with the EPEL8 experience, where there was not even wiki page, where I could state that I don't care about EPEL and I had to reply into every BZ independently, wouldn't it make sense to move EPEL into its own dist-git namespace?
I guess that in the CVS days, having EPEL branch was fine. During PkgDB days, where we could assign maintainer to each branch, it was still fine. But since we lost this ability, isn't it time to rethink the setup? I think this would give more power to EPEL SIG and give relieve to Fedora packagers. Vít Dne 11. 09. 20 v 20:52 Michel Alexandre Salim napsal(a): > 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: <mic...@michel-slm.name> > > == 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 > > > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
