On Wed, Jul 30, 2025 at 1:35 PM Michael J Gruber <m...@fedoraproject.org> wrote: > Is there any valid reason to push a commit to rawhide dist-git without > building it?
To simply save resources. I don't disagree with what you described. There might be perks in having Rawhide built automatically. But in that case I'd like to have an opt-out mechanism (commit message keyword?) to not waste the resources changes where it doesn't make sense. And for the side-tags, as you mentioned. Michal -- Michal Schorm Software Engineer Databases Team Red Hat -- On Wed, Jul 30, 2025 at 1:35 PM Michael J Gruber <m...@fedoraproject.org> wrote: > > 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@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 -- _______________________________________________ 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
