On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood rharwood@redhat.com wrote:
Michel Alexandre Salim michel@michel-slm.name 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.
On Fri, 2020-09-11 at 15:44 -0400, Neal Gompa wrote:
On Fri, Sep 11, 2020 at 3:10 PM Robbie Harwood rharwood@redhat.com wrote:
Michel Alexandre Salim michel@michel-slm.name 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!
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,
epel-devel@lists.fedoraproject.org