Il 10/11/22 21:49, Kevin Fenzi ha scritto: > On Thu, Nov 10, 2022 at 05:16:44PM +0000, Mattia Verga via devel wrote: >> Il 10/11/22 01:58, Kevin Kofler via devel ha scritto: >>> Kevin Kofler via devel wrote: >>> >>>> Mattia Verga via devel wrote: >>>>> with the current workflow, Bodhi doesn't know when a release is freezed. >>>>> There is support for a "Freeze" state, but it was never used. >>>> How do we prevent then that pushes to stable actually move forward? If >>>> rel- eng just hits a different button / runs a different script to push >>>> testing only instead of both testing and stable, that is the "can we push >>>> to stable?" property Bodhi needs to check. >>> PS: The "worst mistake" that can happen then is that if we push only testing >>> to a non-frozen release for whatever reason, the update will be included in >>> that testing push, and then move forward to stable in the next stable push. >>> I do not see this as a real issue. >>> >> I'm working on fixing some bits in Bodhi before proposing to releng the >> use of the 'frozen' release state. That will enable Bodhi to avoid >> pushing updates directly to stable if the release is frozen, as well as >> some small tweaks that were requested and would make life easier for >> releng folks. > Thanks! > > To explain a bit to everyone the current workflow: > > * In non freeze times, we have a cron job that pushes "all pending > updates" at 00:14 UTC every day. This is stable and testing for anything > thats pending moving to a new state. > > * In freezes however, we have to disable the cron job and manually: > - First push branched version updates-testing by itself. > - Then push everything else (minus the branched version). > > This sucks, because it's manual, there's a hour or so wait for > updates-testing to finish before we can do the rest, and you have to > remember to list: > --releases > EPEL-9N,EPEL-7,EPEL-8,F36,F36C,EPEL-8M,EPEL-9,EPEL-8N,F35,F35M,F35C,F36M,F35F,F36F > > If we could just mark branched frozen and have it not push stable there > (without specific builds, because we do still need to push stable > requests through the freeze) that would be great. We could also actually > note this in updates so people don't get confused why their update > didn't get pushed stable. > >> It shouldn't be too hard, it's just that Bodhi code is >> sometimes so contorted that by making a simple change it's easy to break >> something else... moving updates from one state to another and tagging >> builds in the correct way without losing the right track is one of those >> contorted part. > Yeah. ;( > > Thanks again for working on it! > > kevin
Kevin, the PR for Bodhi is nearly finished, it will add support for using the 'frozen' release state to avoid pausing the push cron job and avoid direct pending to stable push of updates when the release is frozen. I'll open a ticket to releng for changing the usual workflow of new releases once the PR gets merged and a new Bodhi release is drafted and pushed to prod. About the avoidance of direct to stable pushing, do you think it needs to be discussed by FESCo? Mattia _______________________________________________ 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
