Works on local preview, so I merge this.

Workflow related question:
I see that this merge request comes from a branch in this repo.
I would have expected it to come from a branch in a fork.
Cons for making branches in the main repo are that
notifications are sent even for unfinished work committed to those branches
and they are also pulled in through git fetch and make work harder,
e.g. tab autocompletion of Git commands will list many branches.
For those reasons I would like to set a policy where pull requests come from branches.
What are the pros, do they outweight the cons?

Only folks that have commit access to this repo can create branches here, everyone else will need to use their own forks.

I don't receive commit notifications, so I wasn't aware of these being sent out.

I understand your cons, but with a repo like this where we must test changes locally, we're going to have to fetch the branch anyway. The other advantage of using branches here is that it makes it easier for the reviewers to make tweaks/rebase etc. before merging in case of complex reviews---instead of waiting for the submitter to make all the necessary changes again and again.

The pros and cons are both quite minor because everything can be done either way. It's just a matter of style. I've been on projects where people prefer branches in the main repo so they can be deleted when the merge is completed---if i use a fork here, you can't delete my branch or make any tweaks before merging---and I've also been on projects where everything must be done via forks with the main repo primarily just using main and devel branches. In fact, they go a step further sometimes and enforce that all commits must be made via pull requests only (I think pagure does have that feature too, not sure how it's implemented in git though).

Yes, the differences are not great.
If there is any wish to use branches in the main repo, I am ok with that.