Why gitlab for rockylinux and gitea for resf?

Rocky Linux General
1

I’m wondering why the fundation git https://git.resf.org is using gitea while rockylinux git is using gitlab https://git.rockylinux.org . Why not simply using gitea on both? Also is this using a sponsored (ultimate) version of rockylinux

2

Initially we chose GitLab for git.rockylinux.org instead of Gitea not only for the CI features we planned on using, but because of the way our tool srpmproc was designed. It allowed us to do subgroups and manage groups and repositories in a hierarchical way that was acceptable for us, easy to manage, and deterministic. srpmproc relies on having a structure like:

.
├── sig
│   └── core
│       ├── modules
│       ├── rpms
│       ├── src
│       └── staging
└── staging
    ├── modules
    ├── patch
    ├── rpms
    └── src

When srpmproc performs work, it looks in the patch group for repositories that match the name of the rpm before importing into rpms. src is used as an alternative import location instead of from git.centos.org or the CentOS Stream GitLab/Fedora Pagure instance.

The subgroup functionality, from what we saw, was a feature not widely implemented. While it is true that there are a couple implementations out there that do indeed provide subgroup support, they did not come with CI potential or other features we thought would be useful to us. Unfortunately, we’ve hit a few roadblocks: Our sponsored ultimate plan is not unlimited. It is has been rather difficult to work around that to allow us to allow more users in and contribute to SIG’s or other work - this makes us be more critical on who we can allow to take one of the license seats. Not only that, the CI features we haven’t touched nor used to a huge extent. We’ve also found the GitLab footprint to be a little too resource hungry for our liking, which is as unfortunate as it sounds.

As a result of this and wanting to have more than just the Rocky Linux project and a central spot for all interests within RESF (like SIG content, software, wiki’s, sites, and so on), git.resf.org was born, using Gitea as the service. Gitea allows anyone to sign up at the Rocky Account System and login almost immediately, and start contributing in some way they see fit, or even start up their own projects without being blocked by license restrictions imposed by us and our potential contributors in GitLab. It is missing some features from GitLab (primarily the subgroup support that we really care about) and the CI system. However, not having CI built-in is not really a loss to us. We plan on implementing woodpecker or another service plus AWX in the coming months.

There are some benefits that we found to using gitea, such as it being written in Golang (which allows us to add features of our own and contribute it back to the Gitea devs, we there may be features that we want and want to contribute back to them). If subgroup support isn’t added upstream, we may spend some cycles to add that ourselves and contribute it back, as there has been a long standing request for it that goes back a couple years on their issue tracker.

Ultimately, Gitea lacks subgroup support for our srpmproc tool. As much as we’d like to use Gitea all the way, that is the primary feature that we are missing. If we add it or upstream adds it, we will end up having a plan of action to migrate from GitLab to Gitea, which may take some time. Another team member mentioned another implementation that has subgroups, but I haven’t personally looked into it yet.

2 Likes
3

thanks for the explanation that makes sense. I’m also thinking to test woodpecker to see how it goes. I do think it shouldn’t be that hard toadd subgroup supports in gitea, the source is very easy to read IMO.