Hi Fabio, On March 9, 2023 1:37:14 PM UTC, Fabio Valentini <decathorpe@xxxxxxxxx> 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). > >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). As someone who accidentally build a package in the wrong time period, I'm very much in favor of preventing this from happening in the future. Thanks for this proposal! Dan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
