Fedora Moves Towards Forgejo

Photo by Jonathan Kemper on Unsplash

The decision to move to Forgejo as the new git forge has reached a new stage. Fedora Linux’s leadership has decided to choose Forgejo as their preferred git forge replacement. There are numerous factors involved in this decision and this article will discuss them, present some background on the process, and invite one more chance for feedback before the formal Fedora Council vote.

Gist of the situation

We’ve known for a long time that the Fedora Project needs a new git forge solution. The software we currently use, Pagure, has served us well. Sadly, it never took off in the wider world. So we had to maintain the Pagure git forge ourselves and use it to build the Fedora Linux releases at the same time. A few years ago, we considered GitLab, and had a lot of discussion… which ultimately didn’t go anywhere. Out of that we got a clear message. It’s important that this crucial part of our infrastructure be free and open source software.

At the Fedora Council’s annual face-to-face meeting in February we discussed a large list of options. By the end of the day, we crossed off all but two: GitLab Community Edition and Forgejo. We also determined that no hosting providers can meet our unique needs; we’ll have to self-host. We then asked the Advanced Reconnaissance Crew (ARC, a subteam of Fedora Infrastructure) to investigate these in more detail. They were particularly asked to look at 1) any show-stopper missing features and 2) maintenance effort and cost.

ARC has presented their initial results (about which Akashdeep goes into detail below). The quick summary: either option could work, and both have some gaps we’ll need to fill. Several things tilt the scales one direction. GitLab CE is “open core”, with some features only in the non-open-source “premium” version (including some we really want). This is both an immediate practical concern and a long-term one. Open core software tends, over time, to get less open (no matter how good the initial intentions). In addition, the Infrastructure team is more comfortable with the Forgejo codebase and the language it is written in.

So, what’s next? The Council, currently, has a clear preference for Forgejo. This is a big decision and we don’t want it to feel rushed. Therefore, we’re opening this up one last time to everyone’s comments. We have created a discussion thread referencing this article to submit your feedback to. You can find it using the #git-forge-future tag. After two weeks, we’ll take our formal vote — and then get on with the work!

– Matthew

How we got here

The earliest attempts to move over to an alternative git forge solution started as early as January 2020. At that time the development work on Pagure became increasingly inconsistent. This resulted in the maintenance costs soaring due to the unmaintained state of the development. Shortly after that, in March 2020, the decision was made to move over to GitLab after evaluating over 300 user stories and a SaaS offering was planned for the Fedora Project. While the development of new features for Pagure slowed down, an exemplary group of contributors stepped up to ensure that the current state of Pagure was maintained well. After a detailed AMA session with folks from GitLab in September 2020, a SaaS offering was announced for Fedora Project in October 2021, and a bunch of sub-projects and SIGs started moving their workflows over to the Fedora Project namespace of GitLab.

While the case looked mostly positive for the sub-projects and SIGs like Fedora Websites and Apps team, there were concerns regarding the scalability in terms of contributor counts and suitability in terms of the Dist Git purposes. This was specifically brought up in the Fedora Council issue ticket discussion and realized at a much later stage in function which led to the initiative request of Dist Git to GitLab from Fedora Infrastructure in February 2023. Fedora Infrastructure worked on an application that helps migrate repositories from Pagure to GitLab through November 2023. By December 2023, the evaluation of Git Forges had become a priority for Fedora Council and a concurrent investigation that explored migrating Dist Git functionality in a forge-agnostic way to another git forge was completed by March 2024.

The Investigation, a.k.a The Prequel!

After the Git Forge alternatives were shortlisted during the Fedora Council F2F Hackfest in February 2024, the Community Linux Engineering (CLE) team (previously called the Community Platform Engineering (CPE) team) were tasked with the investigation. The Advanced Reconnaissance Crew (ARC) sub-team was to report the positives and negatives of each git forge option, while working with various stakeholders across the Fedora Project community to capture the projects requirements for our dist-git. The initiative was led by Tomas Hrcka and Akashdeep Dhar, and Akashdeep also represented the Fedora Councils needs to the team. They began collecting these requirements in the form of user stories in March 2024 to use as the baseline of the investigation. The initiative was then joined by David Kirwan and Ryan Lerch who were able to deploy an instance of both Forgejo and GitLab CE in the CommuniShift app, and the team began validating that each user story worked in each git forge instance. These findings were reported in the official documentation.

The availability of these instances really helped onboard more contributors into the user stories validation efforts. This meant that the focus was not only on the packagers and release engineering workflow but also covered those associated with subprojects/SIGs like Design, Documentation, Accessibility, Websites & Apps, Mindshare etc.

Throughout the investigation, conversations on Fedora Discussion and on the Fedora Project mailing list were happening, making sure Fedoras use cases were being addressed, and the ARC team had presentations during the Fedora Linux 40 Release Party as well as Tomas Hrcka’s talk during the Flock To Fedora 2024 to give this huge change maximum exposure.

Once the investigation completed, Fedora Council was slated to make the final decision on which forge the project would choose to migrate to.

And now the work really begins

Like any other initiative, or large project or piece of work, the plan is never perfect, and this particular effort was quite literally years in the making. The next step for all the parties involved is to have some retrospectives to reflect on how this all went. There are plenty of learnings to be had for sure, and we hope to have a better understanding of how to drive such major decisions in a much better way.

With the investigation on the git forge solutions now wrapped up, we plan to work with Community Linux Engineering (CLE) to direct the migration of Dist Git assets and the conversion of team workflows to the deployed Forgejo Server instance once the decision is formally (and finally!) announced in the coming weeks by Fedora Council.

Pagure Dist Git is connected with a variety of ecosystem services. These include, among others:

Please do not hesitate to reach out to the Fedora Infrastructure team to provide your support. 

Utmost attempts will be made to ensure that the git forge replacement has feature parity with the systems it is attempting to replace (i.e. Pagure Dist Git and Bugzilla). However, it is important to understand that this is a complex undertaking. Most workflows related to various subteams, subprojects and SIGs are likely to remain the same. In some cases we might have to re-imagine the workflows to fit the change (best case scenario). In other cases it may be necessary to deprecate workflows that are no longer reasonably supportable (worst case scenario).

Folks are requested to have an understanding of the user stories that were taken into consideration while comparing the git forge alternatives. Please collaborate with the Fedora Infrastructure team to integrate your specific workflows into the Dist Git Replacement platform.

We look forward to bringing this change to Fedora collaboratively with you in 2025!

Fedora Project community

20 Comments

  1. Darvond

    Hmm. I can’t speak to anyone’s sense of priority, but I’d try to get Packages and COPR up and running first, with The New Hotness™ gets sent to the broom closet, since that’s a terrible, nondescript name.

  2. Peter Boy

    I really appreciate this decision, specifically the decision for really free OSS software and the self-hosting. That’s the only way to fully control our work. I’m looking forward to finally getting rid of all the commercial ingredients of GitLab. Many thanks to everyone who has mastered the difficult decision-making process.

  3. One thing I’m curious about here: has there been any discussion around Fedora / Red Hat helping to sponsor Forgejo development to ensure our chosen solution is viable in the long term?

  4. Why Forgejo, a fork, and not original Gitea?

    • Nolan Poe

      I’d imagine for the same reasons as GitLab: it is uncertain how the product will evolve over time, albeit for different reasons (notably, gitea is owned by a for-profit company, Gitea Ltd, vs forgejo, which is owned by Codeberg e.V., a nonprofit with some actual market presence).

    • I found a comparison here: https://forgejo.org/compare-to-gitea/

      I would also like to know more current details.

  5. joao

    I am not a tech dude, and I think the only commit I did was with my wife ( I love you honey)… but seeing that you mention leaving “pagure” because of being a small, underdeveloped, and less supported app for a “Forgejo”… app that I never heard of and that owned by a company (ok, it is a non profit, but…until when)… not sure if is the correct move… but yeah… to stop is to die. Screw it, let’s do it!

  6. Timothée Ravier

    So, what’s next? The Council, currently, has a clear preference for Forgejo. This is a big decision and we don’t want it to feel rushed. Therefore, we’re opening this up one last time to everyone’s comments. After two weeks, we’ll take our formal vote — and then get on with the work!

    This section asks for feedback but there is no link to where the feedback should be provided.

  7. Be

    This is great news. Pagure has been a bit of an obstacle to me contributing to Fedora in the past. I’m already familiar with Forgejo from using Codeberg. Using software that is already in use by more than just Fedora is a good move; I think this will be mutually beneficial for Fedora and the Forgejo project. I also agree with going with the fully community developed software over open core!

  8. I am joining all the folks applauding this. It’s good that a decision has been finally made, regardless of the winning forge. But it doesn’t hurt that my favorite was picked either.

    For anyone wanting to help with this change in 2025, or for anyone who maintains some of the connected services that were mentioned in the article, is there some SIG, Matrix room, meetings, etc that we could join?

  9. I’ve been using forgejo for a while already and it rocks.

    I haven’t checked if it’s packaged for Fedora already. It would make sense to package itfor EPEL as well.

  10. Rob

    It’s hard to find anything on how forgejo deals with secrets.

    I can only find this https://forgejo.org/docs/v1.21/developer/secrets/

    Does anybody know if forgejo integrates with vaults like openbao/hashicorp ?

  11. fontana

    What about all the core Gitlab CI ?? It’s a crazy decision.

  12. git forge replacement has feature parity with the systems it is attempting to replace (i.e. Pagure Dist Git and Bugzilla)

    Does this mean that the plan is to switch bug reports from Bugzilla to the “Issues” tab inside the forge?

  13. Bill

    I always hate when distros do these 1000% FOSS solutions just to be hipsters. No one knows what Forgejo is and in five years you’ll be back where you started. Use Gitlab and be done with it already.

  14. JF

    Just taking MonoDevelop as a prime example, the moment Fedora somehow competes, encroaches on, or interferes in any way with GitLab; GitLab will take steps to eliminate, slow down, infringe, or interfere with Fedora. GitLab competes with MicroSoft, one of the most ruthless companies to exist. Fighting against such a monster will leave collateral damage to anything that touches the fight. Go with GitLab if you want to sink or swim to the end with them (indirectly fight MicroSoft). Otherwise, it might be better to roll your own forge. Fedora seems to have the resources to do it.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions