Currently the vast majority of SIGs use branches on git.centos.org to maintain their packaging (for example, see systemd); a handful of SIGs use GitLab (for example, see the ISA SIG). Documentation (e.g. the SIG Guide and tooling (such as centpkg) is primarily focused on git.centos.org, which is framed as the primary/default choice to use.

I would like the Board to put out a recommendation for SIGs to use GitLab going forward, and to encourage a migration to GitLab for existing packages. I don't think this needs to be prescriptive, but there is value in keeping things all in the same place, and we should encourage SIGs to do do unless they have a compelling reason not to.

Why GitLab:

• CentOS Stream is already developed on GitLab, including the rpm specs that most SIGs derive from
• GitLab provides features (notably, CI integration via Pipelines and an improved code review flow) that SIGs would like to use and would benefit from
• git.centos.org originally existed to fulfill the source delivery requirement for RHEL, but it hasn't been used for this purpose for over a year, and is pretty much only used by SIGs at this point (plus a handful of additional non-rpm repos such as the Board one)
• git.centos.org is a Pagure deployment; with Fedora moving away from Pagure, it's unclear what its future will look like in the medium to long term

Why not GitLab:

• Fedora is moving to Forgejo, and using GitLab for CentOS would mean deviating from it; on the other hand, using Forejo for CentOS would require another bespoke deployment, and would mean deviating from RHEL and CentOS Stream; closeness to CentOS Stream is likely more valuable for SIGs than closeness to Fedora, especially as many folks involved in SIGs are also working directly on CentOS Stream
• git.centos.org is currently setup to forcibly disallow deleting branches and force pushing, which helps prevent data loss and ensures continuity of provenance for the package sources; GitLab has branch protection rules, but they can be disabled by the project owner, so it's possible one could force push a repo and clobber the existing content; because package builds on CBS always preserve the source RPM, this shouldn't be an issue from a licensing/compliance standpoint (as we will always be able to recover the source from it), but it is not ideal

How to do this:

• Board needs to vote on the overall plan/policy and set direction
• CBS already supports building from GitLab
• centpkg should be updated to default to GitLab (probably to something like https://gitlab.com/CentOS/$sig/rpms/$package)
• documentation such as the SIG Guide needs to be updated
• a migration flow for existing packages needs to be designed, implemented and documented
• non-package repos (board, artwork, etc) need to be migrated (ideally using the pagure-to-gitlab imported so that issues and metadata can be preserved)