On Mon, Feb 14, 2022 at 10:32:40AM -0500, Neal Gompa wrote: > On Mon, Feb 14, 2022 at 3:31 AM Zbigniew Jędrzejewski-Szmek > <zbyszek@xxxxxxxxx> wrote: > > > > On Sun, Feb 13, 2022 at 04:27:36PM -0500, Neal Gompa wrote: > > > I used to be motivated to write such a bot, but after the rpmautospec > > > thing, I'm not going to bother. I wanted rpmautospec to handle > > > rebuilds without commits/changelog bumps, because then we could > > > trigger rebuilds more simply (dependency drift? rebuild in side-tag > > > then merge once all rebuilds are done). Now it would require > > > interacting with Git and changelog bumps. > > > > > > Essentially, this is the model that is used in openSUSE and it's quite > > > a bit less stressful. > > > > I think you're mixing up two things here. We *do* want to record the > > fact that the rebuild happened. It should be visible in the changelog, > > possibly with some explanatory text and a link to a bug number, and > > the new build should have a release bump. The way that we cause all > > those things to happen in Fedora is by commiting to dist-git. With > > rpmautospec this commit might be empty, but it still needs to exist. > > > > Why? Why does that even *matter*? It matters! The fact that the rebuild happened (and why) is very important. Obviously we expect the rebuild to require a different SONAME. So the new package is uninstallable on a system from a few days ago, and the old package is uninstallable on updates systems. So it should be clear that (despite having the same sources) this binary package very much *not the same*. > In ordinary circumstances, there > would be *zero* information to provide anyway. A rebuild should happen > with *no* effort on *anyone's* part. The churn is *already* recorded > by Koji separately in its own metadata. It may be well be recorded in koji, but we don't interact with packages through koji. Users do not and should not directly query koji for information about packages. I agree that we should reduce the effort. But reducing effort != hiding information about the rebuild. > > The bot for rebuilds would need two privileges: for dist-git and for > > koji. And it was the same before rpmautospec and now. And I think it's > > good that rpmautospec deals with changelog/release number generation > > at the level of a single package, and doesn't try to handle additional > > disto-wide jobs. > > > > Touching Dist-Git is hugely problematic. It creates races between > contributors, collaborators, pull requests, etc. The fact that we have > to do that for rebuilds basically forces manual involvement for all > rebuilds. Is this really a problem? If you do "git commit --allow-empty -m 'Rebuild for …' && git push --atomic && fedpkg build" (or some programmatic equivalent), there is a window, but it is very small. Let's say that somebody adds some patches in the meantime. This can happen at three points: before git push, before fedpkg build, or after fedpkg build. If they do so before you did the push, your push fails, they win the race completely, and you can reconsider what to do. If they do this after you started the build, you have won the race and there is no issue. If they do a merge between the push and "fedpkg build", however unlikely this may be, you end up with a rebuild that includes the merged pull request and the commit for rebuild. I think this is still OK. It is also quite unlikely: a push from a local clone would fail because the remote would not be ff, and merging in the pagure web UI would fail because pagure will ask you to refresh the page first. So I think in practice you end up with either side winning the race completely and the other side getting an error that they need to rebase. In case of empty commits there is no conflict possible, so the rebase always trivially succeeds. Zbyszek _______________________________________________ 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
