On Thu, Mar 9, 2023 at 7:37 AM 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).
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@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
_______________________________________________ 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
