On Fri, Sep 12, 2025 at 5:05 AM Karolina Surma <ksu...@redhat.com> wrote: > > >>> The plan, as of now, is: > >>> > >>> 1. Wait for Python 3.14.0rc3 release. > >>> 2. Wait for the Fedora 43 Beta Freeze to finish. > >>> 3. Bump and build all packages in rawhide (except kernel). > >>> 4. FF-merge into f43 and build all packages that match the criteria: > >>> a) the rawhide and f43 branches were not different before 3. > >>> b) they have no update stuck in bodhi/gating. > >>> c) their latest commit hash has been successfully built and shipped > >>> for > >>> Fedora 43. > >>> 5. Open Bodhi updates for packages built for Fedora 43. > >> > >> How are you planning on doing the updates? > >> In groups? one at a time? all at once? > >> > >> I don't think bodhi can handle ~3700 packages in one update. :( > >> > > > > This is something we actually wanted to try for ELN. I feel like I > > remember a conversation from the recent past where we figured out that > > the major impediment to doing this had actually been fixed (it was > > related to HTTP timeouts trying to add all of the packages, I think). > > I'm pretty sure we'd been given the green light to try this for the > > ~2500 packages in ELN. I'm CCing Yaakov Selkowitz and Adam Williamson > > directly who could correct me if I'm misremembering. > > > > So maybe it's worth giving it a try? If it fails, we can always fall > > back to the direct tagging option. > > I'd much prefer not to proceed in yet untested ways, there will be a lot > to handle in a rather short timeframe. > A single Bodhi update with all the builds would have more downsides to > it: any failed gating would stop the whole update; any > updated-in-the-meantime package would require us to bump the one in the > side tag and reset the timer to push to stable. > > > Karolina: Either way, I think we need to do this in a side-tag, if > > only to have an easy way to look up what potentially needs tagging. > > Since we're past the Bodhi activation point, we can't rely on > > automation to create all of the individual updates (short of > > submitting them as a single update from a side-tag). > > Since all the builds will most probably be trigerred by me, a simple > koji query filtering my builds after a given timestamp will be a good > enough solution to make sure we caught them all. > > --- > > Kevin, to your original question: if we create individual updates for > each package, what, except for my work behind the scenes (to determine > built packages and trigger an update for them) can go wrong? Can Bodhi > handle ~3700 individual updates appearing in the span of ~2 days? If so, > we'd most likely go this route. > What is the best way forward from your point of view? >
~3700 individual updates hitting Bodhi over a short period is almost certainly going to cause problems with the load, similar to trying to manually create a single update with all the same packages. To my mind, we have three realistic options here: Option 1) You perform all of the builds, we identify them and tag them manually into Fedora, bypassing Bodhi entirely. Pros: Low resource usage, can be done with or without a side-tag as preferred. (Though a side-tag means it's easier to keep track of which packages were built specifically for this and it allows maintainers to submit their own builds into the side-tag if needed, rather than relying only on Karolina to build everything.) Cons: It bypasses all testing, so we won't know until the next compose attempt whether things still work. Option 2) Build everything into a side-tag, we try submitting the side tag as a Bodhi update Pros: The set of changes gets tested (though it probably fails and needs to waive at least a few cases). It exercises a path ELN wants to take and it provides Fedora data on whether Bodhi can handle such a large update set. Even if Bodhi fails, we still have the option to just migrate everything from the side-tag directly into stable. Cons: If the load generated is too high, we could cause a DoS on Bodhi. Option 3) Don't do this mass-rebuild at all. Pros: No resource usage, no risk to infrastructure. Cons: Low initial end-user performance, as we'll ship Python packages that need to byte-compile every module the first time they are used. Does anyone see an Option 4 somewhere? -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
