For packages for which I am the primary maintainer, I personally like to maintain EPEL branches if the effort required is not very high. That means I tend to give up when I hit unsatisfied dependencies, rather than asking people to branch them, and I tend not to try to rewrite pyproject-rpm-macros-based Python spec files for EPEL7/8 compatibility—but otherwise I do typically support EPEL by default.

I find that EPEL packages mostly hit a version “wall” when an update eventually breaks API or ABI, or the necessary version of a dependency is too new. Then they end up frozen in time for most of the life of the RHEL release. The average effort required for an EPEL branch is thus not very high for a typical package. However, there are cases where it’s possible to backport a commit to fix a CVE or something like that, and that kind of thing can be quite a bit of effort here and there.

I certainly understand why people would not want to support EPEL:

• the lifecycle is long: you’re sometimes stuck with problems you solved in Fedora long ago, and you may eventually have to remember a bunch of packaging practices that are totally irrelevant to Fedora
• maintaining a single spec file in Rawhide that can be fast-forward-merged to all branches may require an impractical mess of conditionals; I prefer instead to let branches diverge and cherry-pick changes as needed, but a fast-forward-based workflow is very important to some packagers
• some people find testing a bit harder, although mock mostly solves this
• people want to focus their efforts on Fedora because it’s personally relevant to them and EPEL isn’t
• some packagers are philosophically only interested in Fedora because they have disagreements with Red Hat or its business model

These are all good reasons.

We’re already doing a pretty heavy lift to support so many neuro-sig packages in Fedora with the number of packagers we have working in the SIG. I tend to think that the status quo of supporting EPEL when a volunteer can be found is reasonable. However, I’m not a neuroscientist—I wouldn’t know if there is a high demand for EPEL support in this corner of the community or not.

For neuro-sig packages for which I am not the primary maintainer, but which I’ve thoroughly audited, and which I am confident are packaged correctly (no license or bundling issues, would pass a re-review under current guidelines), I’m generally willing to volunteer to maintain EPEL branches. I’m not willing to do this for arbitrary neuro-sig packages.

Thanks @music, that makes sense. Yeh, I think individuals should be free to maintain epel branches if they wish, but maybe we as a group currently say that we're not supporting epel, in the sense that we won't maintain epel branches for all our packages.

Does that sound OK to folks?

Does that sound OK to folks?

Sounds good to me.

My approach to EPEL branches is to not bother unless specifically requested. And then on a best effort basis. If it gets too tedious due to missing or outdated dependencies, I won't bother.

Maybe it's an idea to mention it somewhere. Something along the lines of:

Neuro SIG primarily focuses on Fedora branches. If you need a certain package that is (co-)maintained by neuro-sig in EL, please file a bug against that package, mentioning which epel branch you require and we'll see what we can do depending on time and capacity.
If you are already a packager, we are happy to add you as a co-maintainer, so you can take care of porting to any or all EPEL branches.

where others had been maintaining EPEL branches and then orphaned them so we've become primary maintainers

Is that true? I thought orphaning is just that. The package is orphaned regardless of other maintainers still assigned to the package. Of course, they would be the primary suspects for taking over, but they don't have to. And I believe is doen't make them main admins automatically in any way.

where others had been maintaining EPEL branches and then orphaned them so we've become primary maintainers

Is that true? I thought orphaning is just that. The package is orphaned regardless of other maintainers still assigned to the package. Of course, they would be the primary suspects for taking over, but they don't have to. And I believe is doen't make them main admins automatically in any way.

I think @ankursinha was referring to cases where non-neuro-sig packages had EPEL branches, then the packages were orphaned, and we decided to pick them up as neuro-sig packages because they were important dependencies for our packages in Fedora—so, in cases where there wasn’t a separate EPEL maintainer for the package, we also inherited responsibility for the EPEL branches.

Added text here in the PR, please review:

https://pagure.io/neuro-sig/documentation/pull-request/25

Commit 7b96c190 fixes this issue

This ticket has been migrated to the forgejo instance. Please find the new ticket here
https://forge.fedoraproject.org/neuro/NeuroFedora//issues/551