Overall this seems fine to me, a few nitpicks inline...
On Fri, Feb 05, 2021 at 01:51:15PM -0800, Troy Dawson wrote:
> This is a proposal. It's mainly writing down what I think most of us
> agreed on at last weeks EPEL Steering Committee meeting. Feel free to
> continue to discuss and/or have ideas.
> I've been asked by a couple places what the plans were, so I'm writing it here.
>
> Overall Plan:
> - epel-next is an epel branch that is built against CentOS Stream. epel-next
> only has the packages that would be incompatible with released RHEL
> builds, or if an EPEL maintainer is updating a package that will only
> be released to regular EPEL at the next RHEL release.
> - We plan on creating epel9-next when CentOS 9 Stream has a public
> repository. We plan on using the EPEL Packaging SIG to populate it
> early with common packages, although any EPEL package maintainers can
> add their packages whenever they want.
This part I am unsure of. What are 'common packages' ?
We should make sure and ask maintainers to branch and maintain packages
they want for this, but I think it would be odd to just do it without
them being in the loop. We never never 'mass branched' things in the
past. EPEL isn't a specific set of packages, it's packages maintainers
want to maintain. That said, if there's packages of interest where the
maintainers are not interested in epel, the epel sig should definitely
branch and maintain those.
There is a little nuance here. In order to get the repository going, we had to 'mass-branch' about 40 or so packages. fedpkg and some other items require quite a few packages which all have to be done at once. Without those you can't build anything else to put into EPEL... so I would say that EPEL is the specific set of packages in order to get a minimal repository working in the Fedora Build System. Everything else is just extras people add to it.
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org