Kevin Fenzi venit, vidit, dixit 2025-07-29 19:04:31: > I think this is all too big a hammer. > > There's lots of cases where people make small changes and don't think > it's worth doing a new build, but expect it will get picked up in the > next one. > > So, perhaps a more targeted approach might work? Say a week before the > mass rebuild, add a comment to all 'stuck in gating' rawhide updates > saying 'hey, the mass rebuild is starting in a week, please fix this or > the day before the mass rebuild we will unpush this and revert git to > the previous passing builds commit' > > Thats yet more work for releng/qe, but some/much of it might be > automatable. Taking this a bit further: Is there any valid reason to push a commit to rawhide dist-git without building it? We do not expect any "update-shy" users on rawhide, so the usual argument "do not bother users unnecessarily" does not apply here. Indeed, the only reason I can think of is during side-tag work, be it your own small "package plus dependencies" or the larger "rebuild for change X" (new gcc/clang/python/cmake/...). If it weren't for those I'd say we should trigger automatic builds on pushes to the rawhide branch, just as we do automatic bodhi updates on rawhide now. You can always keep a few commits bunched up locally or in a fork/PR if you want to prepare works without building. Indeed, we should work off forks or feature branches more, instead of on the rawhide "production" branch. Depending on how far we want to go we can do either of: - enable automatic koji scratch builds + FTBFS reporting on rawhide pushes - use forks or feature braches for side-tag work - do a scratch build in the rawhide receive hook, i.e. allow only pushes which can be built - enable automatic build on rawhide pushes I know, that's nothing for tomorrow. But maybe the day after the forge move :) Michael -- _______________________________________________ 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
