While added as recently as 2023-02-27, Forgejo supports an integrated continuous integration system called Actions (https://forgejo.org/2023-02-27-forgejo-actions/). For specific purposes where a custom environment is required, even custom Forgejo runners (https://code.forgejo.org/forgejo/runner) can be associated with a certain project repository or project namespace.

  2.  **As a package maintainer, I'd like to be able to control the-new-hotness monitoring status from distgit.**

  3.  **As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.**

        While Forgejo provides for various levels of access control for the repositories and namespaces available, they are not as fine grained as those in GitLab. Only three roles are available for collaborators (https://docs.codeberg.org/collaborating/) of a project (i.e. administrator, read and write).

        Forgejo provides with a comprehensive REST API (https://forgejo.org/docs/latest/user/api-usage/) that can be used to extend the Forgejo instance's functionality using external applications and services. Fedpkg (https://pagure.io/fedpkg) needs to be reworked to associate the REST API endpoint that allows for interacting with the deployed instance in accordance to the REST API schema of Forgejo.

  9.  **As a package maintainer, I want to be able to control all aspects of the pull request process (read comments, reply to comments, approve PRs, merge PRs, etc) via an REST API to allow creation command line tools to automate work that otherwise requires a pointy-clicky web UI.**

  10. **As a package maintainer, I want to be able to mark a PR to automatically merge if-and-only-if a running CI pipeline has succeeded. This allows reviewing and approving a PR, and moving onto new work, without having to wait around to see if CI passes or not. The PR only needs re-visiting manually if CI failed.**

        An auto-merge functionality is not available on Forgejo. While it can be made possible with the use of webhooks called on the event of a successful continuous integration job closure with the combination of Forgejo Actions (https://forgejo.org/docs/v1.20/user/actions/) and Forgejo webhooks (https://forgejo.org/docs/v1.19/user/webhooks/), the setup process cannot be reliably automated and the maintenance adds further workload on the Fedora Infrastructure team.

  14. **As a package maintainer, I would like to see the dependencies of this package, and what packages that are required by this package on web UI.**

        There is no inbuilt method of implementing dependencies across the repositories present on the Forgejo system and hence relying on the MDAPI results is necessitated.

  15. **As a contributor, I want to be able to see who the current maintainer(s) are for a package.**

        Please check the answer to the user story #11.

        While the operation of synchronizing the fork with the more recent changes in the upstream is not as seamless as clicking on a button, Forgejo does note the instructions on how that can be done in the official documentation (https://forgejo.org/docs/latest/user/pull-requests-and-git-flow/#keep-it-up-to-date-rebase-pull-requests-to-upstream). Here again, this is NOT as convenient as doing things with a button click - but hey, it is possible.

  29. **As a package maintainer, I wish we had CI compatible with Github Actions.**

  30. **As a contributor, I'd like to be able to interact with git and distgit via email, namely to reply to issue and PR comments.**

        As mentioned in the answer to the user story #12, the notification settings can not only be used to for obtaining information via email about the activities associated to a certain namespace/project repository but also to reply to issues or pull requests via email as well - establishing a two-way communication medium.

        Please check the answer to the user story #7.

  36. **As a package maintainer, I wish to have a Security tab listing known CVE, and dependencies known CVE for the package.**

        Focussing on making lemonades out of whatever lemons we have at hand, Renovate can be automatically configured to help report CVEs related to the dependencies and remedial pull requests that help with upgrading from the affected version whenever the repositories are created for the first time by releng-scm-bot.

        Please check the answer to the user story #7.

  44. **As an engineer involved in the release process, I want to be able to speed up the creation of blocker bugs and freeze exception bugs with the use of issue ticket templates.**

  45. **As an engineer involved in the release process, I want to be able to limit the access of ticket modification to a certain set of people.**

        Please check the answer to the user story #3.

        Please check the answer to the user story #34.

  56. **As a maintainer, I would like an easy-to-use interface to make suggestions on individual code blocks and suggest changes that the submitter can simply apply.**

  57. **As a package maintainer, I would like to be able to automatically transfer issues between packages (for example from ansible -> ansible-core).**

        This is unfortunately impossible in Forgejo and in order to pull off something like this, one would have to make use of their REST API (https://forgejo.org/docs/latest/user/api-usage/) to close or delete the issue ticket from the source namespace and create a new instance of it at the destination namespace, and point to the issue ticket at the source namespace if closed in the comments.

  58. **A package maintainer, I would like a push hook to block pushes to retired or EOL branches**

  59. **As a package maintainer, I want to be able to grant access to specific branches, or branches matching a pattern, to individual users. In pagure this is referred to as collaborator access.**

        It is possible to configure the access levels per branch dependent on certain branch names or branch names matching a certain pattern in Forgejo. The feature is called "Branch and tag protection (https://forgejo.org/docs/v1.19/user/protection/)".

        Packages (or in this case, their representation as project repositories) have an ability of managing collaborators (https://docs.codeberg.org/collaborating/invite-collaborators/) associated with the project. Checking the packages associated with maintainers and checking maintainers associated with packages should be possible.

  62. **As a packager, I need the new forge to support the orphaned packages process: a maintainer should be able to automatically orphan a package they own and another packager should be able to take ownership through a self-service interface.**

  63. **As a package maintainer, I need the forge to allow me to push branches that do not share history with other branches.**

  64. **As a driveby contributor, who is not a provenpackager (or does not want to use their provenpackager rights), I need to be able to open a Pull Request/Merge Request which introduces zero code changes (it has only empty commit(s) to bump the release for packages using %autorelease).**

        If by empty commits, minimal changes to the specfile is inferred - this should be possible by contributors as long as they have minimal access of being able to READ the said project repository. For more access, it is strongly advised for the contributor to be onboarded onto the process so that they can conveniently keep contributing.

        UNRESOLVED

  70. **As a packager, I'd like to be able to use "draft builds" in merge requests that are then promoted to official builds when the MR is merged. This is to ensure that the build that was tested and approved in the MR is the same one that gets submitted as an erratum.**

  71. **As a packager, I'd like the option to have packages submitted as an erratum automatically when a merge request is merged. Ideally, this would be supplemental to the above "draft builds", just submitting that exact build to errata.**

        Please check the answer to the user story #70.

        Please check the answer to the user story #8 and user story #9.

  79. **As a package maintainer, I want to have syntax highlighting for RPM spec files in the git forge web interface. Currently Pagure and Forgejo have this, but GitLab does not.**

  80. **As a Fedora Badges junkie, I want to be able to receive badges for activities related to dist-git. In technical terms, the dist-git activities must be broadcast to the Fedora Message Bus (or however it's called nowadays).**

        Please check the answer to the user story #51.

        It is possible to run CI jobs (https://docs.gitlab.com/ee/ci/) on GitLab on certain events (like pushes or pull request creation). For specific purposes where a custom environment is required, even custom GitLab runners (https://docs.gitlab.com/runner/) can be associated with a certain project repository or project namespace.

  2.  **As a package maintainer, I'd like to be able to control the-new-hotness monitoring status from distgit.**

  3.  **As a provenpackager, I should have push and merge access to all packages in the Fedora package collection.**

        GitLab allows for a variety of roles (eg. guest, reporter, developer, maintainer, owner etc.) and binding of user accounts with these groups can ensure that the user accounts are provided with necessary permissions (https://docs.gitlab.com/ee/user/permissions.html).

  4.  **As a package maintainer and Fedora tooling maintainer, I'd like to be able to use Packit in both distgit and upstream repositories.**

        Packit has an experimental support for GitLab as long as the GitLab instance is publicly available and Packit is made aware about the identity of the instance by manually configuring webhooks at GitLab end using the steps provided in the docs (https://packit.dev/docs/guide#gitlab).

  5.  **As a package maintainer, I'd like to have easy access links to Koji, Bodhi, and Koschei from the distgit repo.**

        GitLab supports the use of badges (https://docs.gitlab.com/ee/user/project/badges.html) that provide a unified way of presenting condensed pieces of information about the project. While these are mostly used for showing status about the pipeline, statistics about the test coverage and information about the latest release - these can also be used for keeping links for Koji, Bodhi and Koschei for the said project.

  efforts based `investigation <https://fedora-arc.readthedocs.io/en/latest/dist-git-move/index.html>`_

  on Dist Git transfer, the Fedora Council shortlisted a total of two alternatives from

  which one has to be chosen to establish an in-house Fedora Infrastructure deployment

  tasked on listing down the comparison between GitLab and Forgejo to help the community

  governing body to come to a decisive conclusion.