Thanks @t0xic0der for compiling this. I don’t have access to the gitlab instance, but I would like to review a few points which seem off.
#3 push and merge access to all packages (forgejo)
Let’s assume that all packages are under the same organization like they currently are in s.fp.o. Then under organization you can create teams and grant more fine-grained control
Example screenshot
#4 able to use Packit (forgejo)
Gitea and forgejo has good parity on their API with Github, so it is not hard to alter them to support them.
#5 easy access links to Koji, Bodhi, and Koschei
The badge approach seems the most portable, but also forgejo can have plugin, so it could be possible to create a dedicated UI element for these. This would also make other features like orphaning more easy to integrate.
#7 Depends-on/Blocks
With regards to the usage of labels, that misses the mark. Let’s say an issues is both depends on X and blocks Y, than it has relates-to for both issues and has labels blocked + blocks, how do we know which issue it is blocking or depending. Theoretically you could crate labels blocks-X but that becomes unmanageable and clogs the label section.
Thankfully both gitlab and forgejo support dedicated relationship of blocking and dependencies which are accessible via API. Unfortunately this feature is proprietary on Gitlab. Forgejo on the other hand supports it out-of-the-box.
#29 CI compatible with Github Actions
The comparison is a bit more nuanced. Both GH Actions and Gitlab have reusable/template workflows that run pre-defined workflows. But GH Actions also has Actions, i.e. independent components that you can use to build up a workflow, e.g. actions/checkout, actions/setup-python, etc., which most importantly can be centrally defined in a single repo.
Forgejo actions have a similar structure, so I would say only that one would be capable of making compatible GH Actions.
#35 tree of the Depends-on and Blocks bugs
Neither of them have, but it would be a reasonable RFE for forgejo. You can get the list of either depends-on or blocks bugs from the api and plot it externally, but we would need to make sure it is always up-to-date with the status of the bugs, so it should be handled natively.
#37 able to sync a fork with the upstream with a button click (forgejo)
Last time I’ve deployed a gitea repo, I remember having had a sync button as well as a schedule and webhook integration.
HTTPS push requires username / password but it doesn’t accept those for my stg account, and SSH push (after adding my public key to my account) doesn’t work at all, it just hangs forever.