Fedora gathering requirements for a Git forge

Fedora currently uses Pagure to host many of its Git repositories and to handle things like documentation and bug tracking. But Pagure is maintained by the Red Hat Community Platform Engineering (CPE) team, which is currently straining under the load of managing the infrastructure and tools for Fedora and CentOS, while also maintaining the tools used by the Red Hat Enterprise Linux (RHEL) team. That has led to a discussion about identifying the requirements for a "Git forge" and possibly moving away from Pagure.

The conversation started with a post on the Fedora devel mailing list from Leigh Griffin, who is the manager of the CPE team. That message was meant to call attention to a blog post that described the problems that Pagure poses for the CPE team and the path toward finding a solution using the Open Decision Framework (ODF). "We will be seeking input and requirements in an open and transparent manner on the future of a git forge solution which will be run by the CPE team on behalf of the Fedora Community."

The problem statement describes a number of areas where Pagure does not fit within the mission statement for CPE, its current priorities, and the workload for the team. Due to a lack of developer time, Pagure is also falling further and further behind the other Git forges in terms of its feature set. While Pagure was originally developed by CPE member Pierre-Yves Chibon ("pingou") and has been maintained by him and others, largely in their "spare" time, it has languished more recently:

The choices available section lists three possibilities: GitHub, GitLab, and Pagure.

The idea, then, is to gather requirements for a forge from the various users and stakeholders, then to make an "informed decision" on which of the options to pursue.

Listing GitHub, and to a lesser extent GitLab, did not sit well with quite a few who commented in the thread. GitHub is closed source, while GitLab is open core—neither of which are seen as wholly compatible with Fedora. Fabio Valentini asked about GitHub and said that he did not "want to see fedora use a closed-source product for such a core service". Beyond that, he is quite happy with Pagure:

Michael Catanzaro also thought that GitHub should not even be under consideration, which would reduce the choice to either Pagure or the GitLab Community Edition (CE):

There were suggestions for the lesser-known Sourcehut, Gitea, Gogs, and Phabricator forges as possible other options. Opinions differed on whether those would fit the bill, but, like any non-Pagure solution, they would certainly need to be customized for the Fedora use cases. Michal Konecny did not see that as a way forward:

For GitLab, there is the concern that the company will eventually go in a different direction, which could leave users of the community edition behind. As Bruno Wolff III put it:

Much of that discussion was not directly addressing what the CPE team is looking for, however. Clement Verna, instead, differentiated the two separate use cases for how Fedora is using Pagure today. There is pagure.io, which is a collection of various repositories for code, documentation, or simply to have a bug tracker, and the package sources repository (src.fedoraproject.org) that is more tightly integrated with Fedora services and practices. The only real requirement for the former is integration with the Fedora Account System (FAS) to allow for single sign-on, he said, while the latter has a whole host of needs:

Julen Landa Alustiza also split the two use cases; he agreed with Catanzaro that the solution should be open source and self-hosted, though he thought that "self-hosted" could be relaxed if there were a suitable "open source friendly service provider". He added some requirements for both use cases, including privacy and ease of onboarding, along with requirements for each individual use case. Integration with existing Fedora services, such as Bodhi and Koji, is particularly important for the distribution package source repository (which he and others referred to as "distgit").

For pagure.io, he further split the repositories into those used largely for bug tracking (perhaps containing a bit of documentation) and those that host code projects. He had specific suggestions of requirements for each. Standard bug-tracking features and documentation integration are needed for that type of repository, while the code repositories need good searching capabilities as well as a way to see at a glance which repositories are actively changing and which might be good places for newcomers to get started.

Aleksandra Federova suggested splitting off the code-review portion into its own piece. She sees the distribution source repository as a "centrally managed code-review platform". GitHub and GitLab have a workflow that is different from Fedora's; the two styles may clash:

Her suggestion of using Gerrit for code review was not met with much in the way of enthusiasm, but her focus was largely on the two big Git forges under consideration. For Pagure, much of the Fedora-specific work has already been done, though there is still plenty more to do. Her point is that a switch away from Pagure will need to address the impedance mismatch between GitHub/GitLab and Fedora's practices.

The discussion was somewhat unfocused; the idea of moving away from Pagure at all seems to have taken many by surprise. In addition, using the Open Decision Framework is new to some, so it was not clear what the next steps might be. Adam Saleh asked Griffin: "[...] how do we actually get a list of requirements?". Griffin said that the discussion was helping to gather that information, but that it would need to be reshaped:

It is a bit hard to imagine Fedora moving to GitHub for several reasons: the closed-source nature of the platform and the inability to easily integrate it with the distribution's practices are two obvious ones. At first blush, GitLab CE might make a reasonable fit, though it too would need lots of customization. Given that Pagure is mostly filling the role needed at this point, and avoids the pitfalls of either proprietary or open-core code, it would seem to be the obvious answer.

Since any solution will seemingly require extra effort on the part of the CPE team, making a formal decision in favor of Pagure may make it easier for Red Hat to allocate the people and time needed. Neither of the other two possibilities would appear to provide much in the way of development and maintenance time-saving, but whether that is true will become clearer as the process progresses. It should be interesting to watch.