2024 Git Forge Evaluation

News & Announcements Community Blog
1

Originally published at: 2024 Git Forge Evaluation – Fedora Community Blog

Vol. I – Fedora Council 2024 Hackfest

During the Council’s February 2024 hackfest, we discussed the future of Fedora’s git forge – that is, the platform Fedora uses for version control and tracking for packages, source code, documentation, and more. This topic has been around for quite some time. If you are just coming into this conversation, or would like a refresher, #git-forge-future is a good place to start.

Instead of one huge post, the Fedora Council divided the follow-ups from our hack-fest into a mini-series of posts throughout April that will cover all the topics we discussed and made decisions on. In each post, we will walk through one core topic, and share our discussion and thought process on how we reached our outcomes. The first in this series, because why not start strong 🙂 , is an update on our git forge evaluation. Read on for important information.

The Council arrived at two main decisions during this discussion.

Pagure

First, the Council does not see Pagure as a viable git forge solution for Fedora’s future. Instead, we will investigate other git forge options which meet our core community values: Freedom, Features, Friends, First. When a suitable solution is found, the work needed to migrate to the new git forge will be shared.

At a later date, the Council will announce a sunsetting date for Pagure, with ample time for projects to migrate to the replacement.

Options for an alternate git forge

Second, the Council examined a long list of possibilities, and eliminated those that do not fit. We narrowed down the list to these options we think might meet the needs and spirit of Fedora:

  1. GitLab Community Edition
  2. Forgejo (a fork of Gitea)

In both cases, the Council determined that the project will need to run the software in Fedora Infrastructure. Fedora Infrastructure previously investigated hosting possibilities from GitLab at length, and could not find something workable without compromising on our community values for software freedom.

The Council is grateful to everything the Pagure developers have done for us, and acknowledge Pagure’s immense positive impact on Fedora. In the end, these other two options were what the Council felt we could honestly ask our community to use.

The Community Platform Engineering (CPE) Team is a Red Hat-sponsored team that supports Fedora Infrastructure and Release Engineering with staffing, efforts, and resources. The Council will ask the Red Hat CPE to lead the maintenance efforts alongside the community. Therefore, the Council encourages the community to collaborate and support the Red Hat CPE in an in-depth technical evaluation for both options.

When these investigations are complete, the project will have at least two weeks of community discussion on the reports. Then, the Council will select an option and will launch a Community Initiative implementing the migration plan.

Share your feedback on git forge future

To keep track of feedback and conversations in one place, direct all feedback and comments to the #git-forge-future tag on Fedora Discussion. You can reply to an existing topic or start a new one.

This will be a long journey for us to take together as a community. Thank you for your patience and feedback as we go down this road together. Please remember to keep your feedback courteous, respectful, and aligned with the Fedora Code of Conduct.

9 Likes
2

I would like to add for the record: even if we decided to bend on software freedom, GitLab’s per-seat pricing model can’t possibly work for us as a large, open, community project. There are other GitLab hosting providers, but none are approved vendors for Red Hat, who would be footing the bill. So, GitLab hosted options are crossed off the on both principled and pragmatic grounds.

1 Like
3

Anecdata: I use a forgejo instance for some personal things and I love it. It’s also what Codeberg runs on.

4 Likes
4

So at the end is a money problem, no?

5

Well, this would have been so much money. (We were in “bespoke negotiation” territory, and for a starting-point reference consider Pricing | GitLab — and note that everyone who files a ticket or issue or comments on something counts as a “user”.)

2 Likes
6

Why would Fedora even consider the non-Community editions? Is there some feature that is gated on CE, perhaps FAS integration?

7

To be clear, from the prior discussion (and just, generally, in line with Fedora values), in this meeting we crossed everything proprietary off the list early in the discussion. The Council has previously decided that when there’s no alternative for something that we need but which isn’t really a fundamental part of Fedora itself, we can use proprietary software to get things done. In this case, community sentiment[1] is that dist-git at least must be free and open source.

But, yeah — there may be things we want or need that are only in the non-open-source “Ultimate” edition. We’ll have to decide if those are blockers, or if they can be worked around, or done without. (Unfortunately, the open core model makes “re-implemented” somewhat difficult, even if technically possible.) I know that Gitlab did open source some features (I think around single-sign-on?) at GNOME’s request, so that may be a possibility too.

  1. including among current Council members! ↩︎

1 Like
8

I don’t think so. I see it as a a maintenance problem. Maintaining a git forge like Pagure is a huge amount of work, and ultimately, I am not sure it is the best use of Fedora contributor time to build a git forge when there are plenty of other solutions out there that get more maintenance, support, and UI/UX enhancements than Pagure. Pagure served us well, but it is not the shiny tool that it once was in 2016.

So, acknowledging that, it means we have to consider other options. Fedora has many unique requirements which is why using a hosted service is difficult, never mind the fact that there are per-seat pricing requirements, which is a model that might work for an enterprise company but not an inclusive open source community project like Fedora.

1 Like
9

It depends on the feature. $DAYJOB has gotten patches contributed and accepted for bugfixes at least. It seems like large input from the large FOSS projects can influence tiering of features. Larger efforts are best discussed with GitLab before embarking on substantial development (we’ve done this as well) to make sure there’s a shared understanding of the contribution.

AD/LDAP has worked with CE since 2015 or so at least on our internal instances. But yes, there are some things that are useful that are gated. We have ghostflow-director that handles a lot of the workflow things (and additional things that GitLab doesn’t support at any tier). Things like:

  • merge trains (we call it the “stage”)
  • multiple target branches for merges (for backporting)
  • adding review trailers to merge commits (e.g., Reviewed-by) from comments

There are others, but these are likely the most useful to Fedora (or at least as I’ve used it as a packager, not as a developer).

2 Likes
10

This is definitely an interesting point — even if the features don’t exist in the forge itself, we may be able to build small bits of code that cover the deficiency.

11

Yeah. We will likely have to have some bits to get things to work with
our workflow anyhow.

Open core these days always makes me think of things like this:

12

While ghostflow handles GitLab (and Github) today, adding support for forgejo shouldn’t be out of the question. I had some initial attempts at Pagure support, but never had the time to dedicate to it. The deployment story for ghostflow-director probably isn’t 100% scalable for Fedora today, but it’s something that can definitely be worked on.

2 Likes
13

Yeah, that’s something I always worry about too, but I think GitLab has been receptive to doing things in CE to help out the large FOSS project deployments (GNOME, KDE, freedesktop.org, and even discussions about features to entice kernel.org).

14

First, the Council does not see Pagure as a viable git forge solution for Fedora’s future.

what is the problem of pagure ?

nobody maintains pagure maybe that is the main problem ?

15

Pagure is maintained and being actively developed. @wombelix and I have been actively working on it and working toward the 6.0 release. We’ve been working through the backlog and knocking out priority tasks to make it happen.

You can see in the git history that we are doing work: Commits - pagure - Pagure.io

1 Like
16

Commits - pagure - Pagure.io have 2 years (last version and commit) and I can’t run it on F39, we have to assume that we have lack of resources in this project. I like the simplicity of Pagure , maybe pygit2 is slow or have other kind of problems that I’m not aware , that is why I’m asking what is the problem of Pagure ?
fedpkg works with it well ,
have CI integration
have release monitoring

17

You refer to the release tag 5.13.x. There was indeed no release in major version 5 for various reasons. But the master branch is in a good shape, compatible with recent Fedora versions and in my opinion not more or less stable as a previous release tag.

That’s pretty obvious and what I can tell related to multiple decisions throughout the years, like the current one, to get rid of pagure.
Taking a look back, if a fraction of the “move away” effort would have been spend to help me, @ngompa and the other still active contributors, we wouldn’t talk about lack of resources :slight_smile:

I would like to know that too :slight_smile:

I’m biased because I love pagure and invest as much time I can to actively contribute. I don’t know all the history and politics. What I can tell, it has great potential and plays still a crucial role in the daily work in the Fedora project. It does it’s job and I would love to see an invest in pagure instead of the cold shoulder that it receive for so long.

1 Like
18

have you pagure rpms for F39 with git (pre 6) version ?

19

I will gently note that this is not expected - nice bonus if pre release software is nicely packaged but could be a maintenance burden and just slows down the development effort.

And that until the Mailman stack’s packaging gets fixed recently for Mailman V3 we were running our mailing list infra out of… unofficial packages.

So let’s not hold Pagure to an unreasonable standard here

20

I’m personally okay with pagure. It works well, I just wish that the “social aspects” had a bit more work put into them.

For the record, I’m mainly talking about inputting text, I know there’s markdown, but… it’s really not intuitive to the end user lol