On Wed, Jul 07, 2021 at 08:28:20PM -0400, Mohan Boddu wrote: > 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. Yeah, a lot... but not all probibly. > 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. Well, it may be possible to just look at the failures after 2 passes and see whats going on. I don't think we will have thousands of epel9-next packages at that time, probibly hundreds? or even less. > 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? I think we should do 2 and then evaluate if more would help any. Or I suppose we could go for 'steady state'. Ie, keep rebuilding only the failures until the number of them is the same between runs. At that point rebuilding them more won't help any. > 2. Do the mass rebuild builds have to go through bodhi or can we just > directly tag them for stable compose? In order to get a base of rhel9 packages out quickly, I would say just make a stable compose with them. Then, all future ones use bodhi. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
