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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
