---
tags: notes
---

dist-git specifications

# Introduction

[dist-git](https://github.com/release-engineering/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

The following document describes how dist-git is used in Fedora.

## 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 namesapce: 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.