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. > - We plan on creating normal EPEL9 after the RHEL 9.0 GA release, just > like normal. No sooner. All epel9-next packages will be rebuilt on > EPEL9. They will not be "tagged over". This rebuild should be by whoever > built it in epel9-next. This I am also not a fan of. What if you make a epel9-next branch for something, but you don't (for whatever reason) want to put it in epel9? I think we should just open new epel9 branches at epel9 time and maintaienrs can branch and build them (again, if people don't care the epel packagers sig can do all the ones they manage right up front). > > Approximate Timelines: > - All of these timelines depend on (A) CentOS 9 Stream / RHEL9 actual dates > and (B) availability of EPEL volunteers. Please note, EPEL is > completely volunteers, and sometimes "day jobs" make EPEL timelines slip. > - epel9-next - July 2021 > -- CentOS 9 Stream should have a public repository in April 2021 > -- Should take about 3 months to setup > - epel9 - October 2022 > -- RHEL 9.0 should be released around May 2022 > -- Should take about 5 months to setup > -- Note: It takes longer because it has to deal with getting packages > from an internal RHEL repo and all the complications of doing that. > > EPEL Packaging SIG > - We hope to utilize the EPEL Packaging SIG as much as possible. > - This might be as simple as having them rebuild a epel9-next package > on epel9, or possibly maintaining a package when the Fedora packager > does not want to do EPEL. I think simple is better here. > - More details will be coming, but we hope the SIG will help get alot > of the most used EPEL packages into EPEL9 as soon as possible. Thanks for writing all this up! kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
