On Fri, Apr 1, 2022 at 4:27 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > Kamil Dudka <kdudka@xxxxxxxxxx> writes: > > > On Friday, April 1, 2022 12:51:36 PM CEST Michael J Gruber wrote: > > > >> - check whether the "new object name" is descendant of > >> (contains) "old build object name" (rather than "old object name", which > >> would forbid any force push) > >> This would allow to rewrite a branch as long as the last commit hasn't been > >> built yet (but allow only rewrites to commits since the last build). In > >> particular, this would allow to avoid the many "commit missing patch", > >> "actually commit the change", "duh" commits which happen after a successful > >> `fedpkg build --scratch --srpm` followed by a half-(how do you say this > >> nicely)ed commit. > > > > I thought the plan was to use pull requests with some CI checks to > > avoid this. > > I hope not. Unless merging the PRs and kicking off the builds are done > automatically, this'll just be as painful as the current centos > workflow: > > - commit > - push to fork > - open PR > - wait for checks > - click "merge" button > - wait for bots > - kick off build > > compared with: > > - fedpkg commit -sc && fedpkg push && fedpkg build > > Context switches for maintainers are expensive! And while I don't > personally think the "oops fixup" commits are a problem, a "PR with CI" > workflow doesn't get rid of them by any means. Why not this then: - fedpkg commit -sc && fedpkg scratch-build --srpm && fedpkg push && fedpkg build Yes, it'll still take longer, but you won't need to context switch unless the scratch build fails (which would make you do a fixup commit + another build anyway). This workflow allows you to amend the commit until you get a successful scratch build, after which it is unlikely that you would need to commit another fixup. -- Ondrej Mosnacek Software Engineer, Linux Security - SELinux kernel Red Hat, Inc. _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
