On Thu, Mar 9, 2023 at 7:37 AM Fabio Valentini <decatho...@gmail.com> wrote:
> Hi all, > > As a follow-up from a recent discussion on Matrix/IRC, I'm proposing > the following change to the development cycle / release schedule: > > "Koji builds are blocked while mass branching and updates-testing > enablement are in progress." > > That's it, that's the entire RFC. > > Roughly every six months, I run a check for updates that are present > in the current "stable" release, but missing from "branched", and > every six months, there's a non-negligible number of builds and / or > bodhi updates that get stuck in a void because they just happened to > have been run at the exact worst moment. > > In my opinion, the benefits of implementing this change (less releng > time spent on fixing builds that are stuck in an inconsistent state) > would outweigh the downsides (two windows of a few hours each during > the early development cycle where no builds can be launched). > > Issues that I see with builds that just "happened to be in the wrong > place at the wrong time" fall broadly into two categories (though I > have seen other types of problems that are more rare): > > 1. Builds launched while the mass branching is in progress have the > fcXX (where XX = old-rawhide / branched) dist-tag, but only gets > tagged with fXY (XY = new-rawhide) by koji. This results in them only > being available in the rawhide repos, and not from "branched" at all. > Just resubmitting the build for "branched" doesn't work, because the > wrong dist-tag causes NVR conflicts. Fixing this requires either > releng intervention (useless busywork) or bumping the release and > submitting new builds for *both rawhide and branched* (waste of > resources). > I think this can be resolved by changing the branching process, though there would still be a small race condition window. We used to lock everything when branching when we used CVS and went to a lot of effort not to lock everything. Doing the koji side completely before doing anything in git should help significantly here. you can also disable all the builders and wait for the active builds to complete then do everything, that way new builds will queue up and wait for the builders to be renabled. > 2. Builds launched just before updates-testing enablement can get > stuck in "testing" state before there is an actual updates-testing > repo, and are hence not available from *any* repository (for testing?) > during the beta freeze, but will get pushed to stable afterwards. This > results in users who want to test the beta release (or "pre-beta" with > updates-testing enabled) to not see these updates at all, but they > will be pushed to "stable" immediately after the beta freeze is lifted > (i.e. without *any* amount of testing). > I do not understand how this is at all possible. If a build has the tag to be stable it will show up freeze or not. it may not be in the beta compose, but will be in the nightly composes and being tested and available there. Dennis Fabio > _______________________________________________ > 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 >
_______________________________________________ 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
