The Fedora Council is pleased to announce that we have chosen Forgejo as the replacement for our git forge! That means you’ll see Forgejo powering our package sources (src.fedoraproject.org) as well as our general git forge (what pagure.io is today). It has been a long road to get here, and we cannot thank the Fedora community enough for your patience and support throughout. 

For deeper context into what went into this decision, we will walk you through the last few months from the council’s perspective. You may want to grab a tea or coffee or beverage — this might be a few paragraphs long 🙂

In the beginning

If you’d like to read more about the early stages of this saga, please visit the announcement from two weeks ago. There are lots of helpful links to more documentation about the investigation of both GitLab and Forgejo, as well as more detail about the history of this change.

We have liftoff!

This all officially started after the Council’s face-to-face meeting in February 2024. We made a list of all potential replacements for Pagure, including Pagure itself. Over the course of several hours, we ruled out almost all of the candidates, for various reasons, and in the end we were left with Forgejo and GitLab CE (self-hosted). We published a blog post about this, and then got to work figuring out requirements to hand to the team doing this investigation. As Fedora Council is a main governing body of the entire project, we tried to keep the requirements to the project’s holistic needs, and not weigh in on too many technical aspects — those would be better reviewed by our community and FESCo. So, with two options to choose from and a list of requirements to investigate them against, we began the formation of the git forge investigation 2024.We just needed the right folks to be part of the investigation team. Enter CLE!

The council made an official request to the Community Linux Engineering team (CLE, which includes the former CPE) to drive an investigation into the two options. The investigation team, ARC (“Advance Recon Crew”) launched the investigation in May 2024 with a call to all folks who would be impacted by a change to our current dist-git setup. They asked for use-cases in the form of user stories so they had a better picture of what Fedora needs. Since dist-git has more specific technical demands than general project hosting, the investigation centred around dist-git — we started with the hardest part first!

Throughout 2024, the investigation team promoted awareness of the upcoming change by speaking at Fedora release parties and at Flock, and by the summer they had managed to deploy a test instance of each forge option, to evaluate  each use case. The results of that are can be read at the ARC team’s read-the-docs page. 

Options, so many options!

The Council requested a write up comparing each option. It was sweet to hear that there are no insurmountable ‘blockers’ for Fedora in terms of technical effort, but also bittersweet as it was going to be harder to make a final decision.

Accessibility

Both projects prioritize accessibility as a core value and implement UI best practices. However, Forgejo faces challenges, as it heavily relies on Fomantic UI, a framework not inherently accessibility-friendly. While Forgejo’s upstream, Gitea, applies patches to improve accessibility, significant issues remain that require time and effort to resolve. Accessibility is important to Fedora, and a strategic priority for the Council, and Forgejo lists it as one of their core values, so we hope to collaborate on making this better.

Functionality

In terms of issue tracking, GitLab limits some critical features to premium tiers, while Forgejo offers all functionality without restrictions or fees.

An interesting distinction is syntax highlighting: both solutions leverage the same JavaScript library, but Forgejo uniquely highlights RPM spec files by default.

GitLab supports auto-merging of merge requests, allowing users to define rules for automatic merges once conditions are met. Forgejo lacks this feature. However, its implementation of “actions” is API-compatible with GitHub Actions, enabling potential integration with third-party services or custom pipelines—albeit with significant development effort required.

Maintenance

Forgejo’s deployment documentation is relatively sparse, but Codeberg, a reference deployment, successfully supports over 143,000 registered users. The deployment is documented and available in Codeberg Infrastructure repositories (They even use Ansible!). GitLab offers more comprehensive versioned documentation, covering deployment, security, and maintenance. Additionally, GitLab provides an official OpenShift operator for GitLab CE, ensuring seamless container-based deployment.

Contribution

GitLab CE operates under the MIT license, while Forgejo uses GPLv3 or later.

• GitLab CE: Actively synchronizes with its proprietary upstream, which is highly active (over 30,000 commits to the main branch in 2024, from 1435 distinct contributors). However, contributions are only accepted for the Enterprise Edition (EE). The official “community fork” has only 5 accepted merge requests ever.

• Forgejo: While less active upstream (about 3500 commits in 2024, from 250 contributors), Forgejo and its base, Gitea, accept contributions openly from all users, clearly a more inclusive development process.

Quality (Fedora QA)

By the time Fedora QA were in a position to look into each option for their use cases, the Council had already been trending towards choosing Forgejo. So in an effort to reduce time, we asked the QA team to just look at Forgejo when validating their use cases. QA found the majority of their use cases to be either working or likely working (meaning even though the Forgejo configuration and deployment details are not completely finalized at the moment, and see a path forward for satisfying their needs). However, they did identify several concerning shortcomings in Forgejo’s issue tracking features. None of them seem to be a complete blocker, at least from QA perspective, but they are highly-visible regressions and other parties might be affected by them as well, and will need to be prioritized in reconciling them before a migration can happen. Priority will be given to having the ability to move issues between repos to help with debugging, being able to search all of dist-git combined in order to avoid duplication of bugs being reported or opened, and to be able to create private issues in public repositories.

Reaching the decision

After tracking the investigation for months, the Fedora Council had multiple meetings both on Matrix chat and in video conferences to ask questions about each forge and to improve our understanding of just how big this change will be. In one meeting, the council needed to refresh our requirements list to make sure we were asking for the right information at the end of the report. We had initially wanted no recommendation from the investigation team from the report, however as the work continued, it became necessary to change that to needing a recommendation. The investigation team could find no technical blockers to recommend one forge over another, both will require work.  This brought about several conversations amongst council members as to whether they already had a preference for one option or the other. It was great conversation and it appeared that once again Forgejo was taking the lead on virtue of their open-source nature. Some of us on the council liked the well documented, and somewhat familiar option of GitLab, but when faced with the reality that sometime in the near future, Fedora may find itself needing to make changes to our git forge, and one option might require money we don’t have, or not allow the changes we might need to make, and we did not want to limit the project in any way. And so, Forgejo galloped on down to the finish line!

One pivotal conversation was with the ARC team lead, where they walked the council through a mapping of use cases. This included complexity estimates for the sysadmin and developer work needed to deploy either option.

The diagram shows personas in the project like packagers, developers, etc and how they interact with a git forge in Fedora. The numbers indicate how complex the interaction is with the forge, with 1 being low and 10 being highest. These complexity numbers were determined from lack of documentation on how the services and features work in Fedora. Added caution was used as the team was unfamiliar with how some personas work, and with no documentation to work from….well, best put 10’s across the board for some things 🙂 For others, like packaging, and being a general user of Fedora  and other similar personas, because of good documentation available on those workflows, the team felt like they could follow the logic and did not add any complexity number. That is not to say that there won’t be any difficulties to overcome when we deploy and begin to use Forgejo for these personas, but I think we can all agree that the complexity can certainly lessen a bit when you have good (or any!) documentation on how something is set up and you feel more confident you can make it work!

After we announced the Council’s lean towards Forgejo, we asked the community for one last sanity check on this big decision. Two weeks have passed, and the feedback has been largely positive with no technical objections to this choice. A Council ticket captured: APPROVED by unanimous consensus with no abstentions (+9, 0, 0). Fedora will move to Forgejo!

State of Play

 We have made the decision to choose Forgejo, and will look to our community to help plan and execute the migration. The CLE team has already done some investigation into how our dist-git setup works, so if you would like to learn about it you can read the overview here. Please be prepared to see this work happening slowly, and likely across multiple releases. We will continue to focus on dist-git functionality first, and eventually finish with project hosting. This will take time and your patience will be invaluable and greatly appreciated. For right now, a lot of folks are away from their computers to enjoy some time with friends and family so we will start this change in January.

The next chapter

There is a lot still unwritten for Fedora’s git forge change. We are only scratching the surface, but we have taken an important step forward – choosing our path. We will have to take our time and break this down into smaller phases so we don’t get overwhelmed, so if you’re wondering about bugzilla and the project’s bug tracking future, don’t worry – we are too! We will be exploring that too if not exactly as part of this per se, but rather a logical next step and something we will be keeping in mind. Our focus is to deploy Forgejo, develop the features the project needs to build and release Fedora Linux and function as a project, and replace the existing forges with the new solution.

In January 2025, there will be open meetings happening every Wednesday from January 15th on Matrix. If you would like to be involved with this work, or have any questions, please do join that meeting. The details can be found on the releases calendar in Fedocal. We will also use the tag #git-forge-future when posting on discussion.fpo and we intend to see this plan take the form of an overall change request not tied to any release, with several smaller change requests tied to it which we hope will allow us make this project-wide change in controlled and careful increments.

On behalf of the Fedora Council, I would like to once again thank you all for your contribution to this change, and most importantly to the investigation team who took this on and have done an excellent job reviewing Forgejo for Fedora. I look forward to 2025, it will be a big year!