Fedora Project migration
Fedora Project | Migration Tracker
This currently a Work In Progress issue :-)
Background
dist-git is a solution used by the Fedora and CentOS project to manage the collections of components released by these projects in git. The solution is composed of the following:
- git repository
- look a side cache (contains project source tar ball)
- scripts to manage git repo + look a side cache
Goals
We would like to investigate GitLab to provide an interface for Fedora's dist-git.
Quick Facts
- Timeline. - TBD
- Product. - GitLab Community Edition
Current Tooling and Replacements
Authentication & Authorization
Cloning a repository
Currently anyone is allowed to clone a repository using https.
Pushing changes to a repository
Different type of users can push changes to a repository.
packagers
The most common case is the maintainer of the repository. To be able to maintain a repository a community member needs to be a member of the packager group in the Fedora Account System (FAS).
Being a member of that group allows to clone and push changes to repository using the ssh protocol.
Packager SSH keys are configured in the Fedora Account System and synced on the dist-git server.
A packager can be a project maintainer (access to the project settings) or project co-maintainer (commit access only).
provenpackagers
Members of the provenpackager group have commit access to all the projects (except 2 projects for legal reasons), they are trusted to perform mass changes. provenpackager are not listed in each project as members and they won't get notifications for all projects.
release engineers
Members of the releng group are allowed to commit on all the projects with no exceptions.
Special Interest Group
This is a group of community members that are working together on a collection of package. Access is managed a the group level.
Login to the web service
Community members are using Single Sign On (SSO) provided by either Fedora Account System or CentOS Account System. This is using OpenID Connect.
Questions
- We need help to best design how to organize the groups and premission in GitLab.
Git actions and performances
Number of repositories
Container namespace : 75
Flatpaks namespace: 87
Modules namespace: 185
Tests namespace: 17
Rpms namespace: 30169
~ 30,000 repositories
Commits pushed over 1 month
Average ~10,000 commits per months
Mass rebuild
20,000 commits 1 one week from the same user, happens twice a year.
Branching Strategy
We are using branches to track a specific version of a release, for example the f32 branch is used to maintain the Fedora 32 release. These branches are automatically created to the repositories when starting to work on a new version.
'refs/heads/f[0-9]+', 'refs/tags/.', 'refs/heads/master', 'refs/heads/.' needs to be protected and only an admin user should be able to create these branches.
No branches can ever be deleted, except by Admin user. Branch commit access can be configure per maintainer, ie maintainer A can commit to branch f[0-9]+ but not to branch epel8, maintainer B can commit to branch epel8 but not to branch f[0-9]+.
Ideally we can hide or archive old branches, for example f28 was EOL (End of life) more than 1 year ago, so we don't need to display it.
Project Creation
Admin user are the only one allowed to create projects. Similarely only Admin can delete a project.
Git seed and Tarball
We're currently shipping a daily bundle of all the git repo to make it easier to download for people with low bandwith. We're currently shipping a daily tarball of all the spec files in all the git repository to make it easier for people to analyze and make stats of them.
This is currently done by scripts, we have to know if we can run such scripts against an hosted instance.
Special API endpoint
We need a single place where we can retrieve the list of people and group that should be CC'ed on tickets in bugzilla for all the projects hosted.
This is to avoid having to do 20k+ requests just to gather this information.
We currently have a single json document generated on a regular basis from the database.
Related Issues
Blockers
Urgent
Important but not urgent
-
Custom fields --> #1906
-
We want to leverage the Badges feature to offer links to other services. In the current state we would have to configure the badges for 30,000+ projects. Having #22278 would allow us to do that configuration at a group level.
Nice to have
- [ ]
/cc @nuritzi