Cristian Le

I am a bit confused about why you want to add a new release with no changes. Is it to make sure that it pulls the latest `BuildRequires`? How about...

> But about `build_koji` is not triggered on arbitrary commits, I think you are right. By definition of `%autorelease`, it should always submit a new koji build when a new...

Ok I see @ljavorsk. You have not set yourself as `allowed_committers`? Is that the issue? I see that there are already relevant examples [here](https://packit.dev/docs/configuration/examples/), probably they should be made more...

Hmm, that is an undesired behaviour when we have `%autorelease`. E.g. if we are changing a patch in `SOURCE1`, we want it to trigger a build as well. This should...

> The concern is if those comments would leak in %autochangelog My understanding of autochangelog is that those comments will be used until a new change in `changelog` is detected,...

That would make config files generally simpler. But I can also see situations where you would want the current behaviour. Maybe we can just have some better variables for these:...

To hook to the `packit-service`, I think [this part](https://github.com/packit/packit/blob/7ecfe4594ac59a5e0f479ef343482e921784362f/packit/api.py#L1575-L1674) needs to be abstracted.

Oh yeah, you will not be able to build in copr because there is no internet access and all of the tests go through `testing-farm` :worried:. That is a conundrum....

Context. This is an issue when `origin` is a downstream repo and `upstream_project_url` is not set. Also related, this part is flaky depending on the order of remotes: https://github.com/packit/packit/blob/42961092dbc5b5598c05f1d13d260cce8a1365a9/packit/cli/utils.py#L320-L336

Things are a bit more complicated than I thought, and it needs more documentation on how to interact in a downstream dist-git. E.g. even after I updated the spec file,...