Hello all, While we are already working on epel9-next enablement, there was a discussion about how to handle epel9 when rhel9 goes GA. It is safe to assume that a lot of the builds that are already in epel9-next at that point of time should work on rhel9. There were couple of ideas thrown around from doing nothing to tagging epel9-next builds to epel9, but I think the best way to solve this is, mass branching the packages that have epel9-next branch and create epel9 branch from it and then running a mass rebuild without any changes to spec files. As epel9-next builds will already have a .el9.next dist tag, we can simply rebuild whatever there is in epel9 branch (after branching epel9 branch from epel9-next branch). Since the builds are done in alphanumerical order and does not preserve build order, we might have to run this mass rebuild a few times (thinking of 5 times) on the failed builds to get most of the builds. This doesn't involve changing the spec files, just resubmitting the failed tasks. Also, people who wish to opt out of this mass rebuild can add 'noautobuild' file to the epel9-next branch beforehand, this however does not stop from creating the epel9 branch, just the package won't be included in the rebuild. The idea here is, if the maintainer wishes to support epel9-next, their final goal is to maintain the package for epel9. So, we give them a branch, but will not rebuild their package as they might have wanted to build their packages in the correct build order (cough cough KDE :D). This gives us a working epel9 with a bunch of working builds in a few days after rhel9 GA and also we can create ftbfs bugs for those that failed in the mass rebuild which will help maintainers to identify and fix the issues. Couple of questions that need to be answered here: 1. Is 5 times of rebuilds good enough or do we need more? 2. Do the mass rebuild builds have to go through bodhi or can we just directly tag them for stable compose? Any suggestions appreciated. Thanks. _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
