FTR, I'm not so sure about this idea, but I think it merits further discussion. There seemed to be some interest in the meeting.

We discussed this at today's Steering Committee meeting. We didn't reach a conclusion, but one alternative suggestion from @tdawson did stand out to me.

What about if we automatically branch a package if it was in the previous epel release. Not do anything to it, just branch it. Branching has been our biggest issue.

I like this idea. I think it would result in a few more questions like "I see it's branched, why isn't it built", but we could mitigate those with an FAQ entry. I agree that the biggest roadblock is usually who can request the branch and then waiting for the branch to be created. If we auto-branched, then anyone could start working on a new EPEL package by sending a PR to the initialized epel[0-9]+ branch. This might make the workflow more obvious to maintainers that aren't as familiar with EPEL, as they would be able to see it's just another branch they can run fedpkg build in. Proven packagers could even merge such PRs in a pinch. If later on it's decided that the branch isn't needed, it's quick and easy to retire it.

I think this is a better solution than adding @epel-packagers-sig to the package permissions. I especially like how it eliminates the routine delay in requesting EPEL branches for most packages. I'm kinda worried the SIG is turning into a bugzilla dumping ground. We really should be encouraging Fedora maintainers to be involved in EPEL directly (or adding co-maintainers who are).

What about if we automatically branch a package if it was in the previous epel release. Not do anything to it, just branch it. Branching has been our biggest issue.

I like this idea. I think it would result in a few more questions like "I see it's branched, why isn't it built", but we could mitigate those with an FAQ entry.

I would think that the bigger thing is that we'd need to clarify to packagers that their packages aren't being built for the new EPEL verison, just branched. Otherwise, it would seem like we're completely changing the very ingrained policy.

This might make the workflow more obvious to maintainers that aren't as familiar with EPEL, as they would be able to see it's just another branch they can run fedpkg build in.

That sounds like a much more elegant process than creating bugs and NEEDINFOing people who don't respond. This would help increase participation, make the process more transparent, and allow for CI testing.

I'm kinda worried the SIG is turning into a bugzilla dumping ground.

Disclaimer: I'm not part of the epel-packagers-sig. Yeah. I think SIG ownership makes sense for e.g. Rust packages where one person does a lot of the work, but I'm not sure it's the best solution here.

We really should be encouraging Fedora maintainers to be involved in EPEL directly (or adding co-maintainers who are).

I agree. I think the stalled EPEL request process or otherwise adding collaborators should be a last resort. Having an extra co-maintainer instead of an EPEL collaborator benefits both Fedora and EPEL.

I would think that the bigger thing is that we'd need to clarify to packagers that their packages aren't being built for the new EPEL verison, just branched. Otherwise, it would seem like we're completely changing the very ingrained policy.

Yes, I'm thinking that this is something we could start with EPEL 10 with lots of publicity/notification before and during. We would also need to update the EPEL Package Request guide with steps to check for an existing branch and send a PR if possible. If the rawhide branch builds without modification for the new EPEL target, it could be as simple as navigating to https://src.fedoraproject.org/rpms/example/diff/epel10..rawhide, filling out a summary, and hitting submit. That would also give us a scratch build that could let the maintainer know up front that it builds in koji on all arches successfully.

That sounds like a much more elegant process than creating bugs and NEEDINFOing people who don't respond. This would help increase participation, make the process more transparent, and allow for CI testing.

100% agree.

We discussed this more at today's Steering Committee meeting. The autobranching idea seems to be gaining traction. No one appears to be outright against it. It appears to be a more favorable solution than automatically adding the EPEL Packagers SIG to packages with EPEL branches (perhaps we should change the subject of this issue to reflect that). Most of the discussion centered around the implementation. The original suggestion was to base the epel10 autobranching decision on the existence of an epel9 branch. Some would like to limit that to packages that had been built for epel9, not just branched. Another suggestion was to base the logic on whether the package had been configured as a "workload" in ELN Extras. A combination of these could also be useful. No matter what choice we go with, we will also need to ensure that anything in EL10 itself is blocked from branching.

At this week's meeting we more or less settled on a basic plan for this. Someone (perhaps myself) will write automation (likely based on Fedora's existing mass-branch automation) to automatically create epel10 branches for every package that meets the following conditions:

• has pushed an epel9 build to stable or is part of a configured ELN Extras workload
• not present in CentOS Stream 10 composes (indicating it will be in RHEL 10)
• not on an opt-out exception list

I think we should mandate it be part of ELN Extras for autobranching, otherwise it wouldn't be validated to branch with the separation of packages. It would also ensure that we know what the build dependency map looks like and get that squared away between RHEL and EPEL.

I think it's time to revisit this. Previously in this issue I pointed out one thing in particular.

I especially like how it eliminates the routine delay in requesting EPEL branches for most packages.

The situation is actually quite different from when we talked about this previously. There is now a "toddler" program that automatically processes branch requests, as opposed to the old process that required manual human processing. Anecdotally, I would say the old process would take a few hours to a few days to get an EPEL branch created. Now, it usually happens in less than a minute. Now that the delay has been essentially eliminated, I'm not sure it worth the effort to do a mass-branching.

Adding to the agenda for the next steering committee meeting.

We discussed this at today's EPEL Steering Committee meeting.

https://meetbot.fedoraproject.org/fedora-meeting/2023-10-11/epel.2023-10-11-20.00.html

We agreed that with the faster branch creation these days it is no longer necessary to automatically create EPEL 10 branches.