Hi Fabio,

On March 9, 2023 1:37:14 PM UTC, 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).
>
>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@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

Reply via email to