[EPEL-devel] Re: Proposing an EPEL packaging SIG
We discussed the proposal a bit at today's EPEL SC meeting; here's a revised proposal taking into account the suggestions from the meeting and earlier in this list. ## The SIG - bstinson pointed out that epel-wranglers was started to address the same issue, we can resurrect that - we want to limit the access to epel* branches only, not all branches, as suggested both here and at the meeting. Any change the epel- wranglers want to make to the Rawhide branch can be done as a PR - the EPEL branch will likely diverge from master over time anyway - the collaborator permission (available since August, yay) can be used for such granular access - nirik pointed out that collaborators can't yet request new branches, if the proposal is approved we can work on making the `fedpkg request-branch` flow support this - carlwgeorge suggested getting the group up and running first, and working on automation later ## Workflow - no objection that I recall to having epel-wranglers automatically get access if the Fedora maintainers do not respond (so we can circumvent needing to do a non-responsive maintainer request) - we probably won't have this automated at the beginning, see above - down the line, epel-wranglers need to decide on what to do with releases they no longer want to support (e.g. when everyone involved only cares about epel10 and epel9 and there's a CVE affecting epel8). the normal orphan process probably works - we announce the package is being orphaned by the group on epel-devel Let's continue discussing the proposal in this thread, as suggested during the meeting. Thanks all, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposing an EPEL packaging SIG
On Fri, 2020-09-11 at 15:44 -0400, Neal Gompa wrote: > On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood > wrote: > > Michel Alexandre Salim writes: > > > > > * 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 > > > > Unless I've missed something, we still don't have per-branch ACLs > > in > > dist-git. > > > > I don't think it's okay to force maintainers to give you admin or > > commit > > to their packages just because you want them in EPEL. > > Fair enough, I think if the maintainer does not explicitly grant permission, any automatic grant should be limited to epel-* branches. > > (I'm also not one of the kind of people who really like having one > > spec > > file for all versions of the package, but I know others disagree > > with me > > on this. Certainly if hypothetically I didn't want to maintain an > > EPEL > > package I wouldn't want its logic /also/ foisted on me in rawhide.) > > Yeah. I'm in-between on this, I try to get changes into the Rawhide branch if they are not too intrusive, and keep them in the EPEL branches if they are. EPEL maintainers can always just submit a PR against the Rawhide branch so not having automatic access is no big deal. > > We have per-branch ACLs in Dist-Git since early August. The > collaborator role in Pagure lets you grant people commit access for > specific branches. > Yeah, the collaborator role is what I had in mind but I didn't remember the exact name when writing it (should have just looked it up in src.fedoraproject.org). Thanks Neal! -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed message part ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: Proposing an EPEL packaging SIG
On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood wrote: > > Michel Alexandre Salim writes: > > > * 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 > > Unless I've missed something, we still don't have per-branch ACLs in > dist-git. > > I don't think it's okay to force maintainers to give you admin or commit > to their packages just because you want them in EPEL. > > (I'm also not one of the kind of people who really like having one spec > file for all versions of the package, but I know others disagree with me > on this. Certainly if hypothetically I didn't want to maintain an EPEL > package I wouldn't want its logic /also/ foisted on me in rawhide.) > We have per-branch ACLs in Dist-Git since early August. The collaborator role in Pagure lets you grant people commit access for specific branches. -- 真実はいつも一つ！/ Always, there's only one truth! ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
[EPEL-devel] Proposing an EPEL packaging SIG
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: == 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/mic...@michel-slm.name chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 signature.asc Description: This is a digitally signed
