On Tue, Jan 21, 2025 at 9:14 AM Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> wrote: > > On Tue, Jan 21, 2025 at 02:09:51PM +0100, Fabio Valentini wrote: > > Workflow with non-vendored dependencies: > > - update library or backport fix > > - submit rebuilds of dependent applications (with rpmautospec, those > > are no-change commits) > > > > Workflow with vendored dependencies: > > - check out application and vendored sources > > - patch vendored sources > > - repeat checkout / patching for *every affected application* > > > > Yes, Neal, making changes so that no-change rebuilds don't require git > > commits would make workflow 1 even more streamlined. Waiting for your > > proposal on how to achieve this ;) > > At the fundamental level, such automation would effectively do two > steps: > 1. create a no-change commit like we do now, > 2. push the commit and fire off a build. > > (I think we want to keep 1. unchanged. We need to store the information > why did the rebuild and why _somewhere_. Either we keep the current > mechanism which works well and is easy for humans to interact with, > or we store this information in some external database and create new > tools to query this. I don't think we want to do this.) > I think this is the fundamental disagreement we're going to have. I think no-change rebuilds should be happening with such frequency that the reasons just stop mattering. Git commits for no-change rebuilds are the fundamental reason why we have so many provenpackagers. They need to do it for the most banal things, the most common being rebuilds when a dependency is upgraded and has a soname bump. And this causes us real workflow problems, such as update collisions. Just recently, we had a problem reconciling GStreamer and Qt updates because an intersection of packages had to be manually rebuild for each update in a particular order. But that would not have been necessary if no-change rebuilds were just automatically added to side tags (also for single build updates to automatically be converted to side tags updates for this purpose). If our buildsystem is doing the right thing, we will always have a record of that information in Koji, regardless of Git. We can trace through historical builds fairly easily. But I have never felt that requiring commits for no-change rebuilds is worth the cost of making everyone have to do manual toil. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
