Contributing to CentOS Stream
If you want to contribute to CentOS Stream, you need to have an account in CentOS FAS.
2. Getting the repository
Once your account is set up, you can proceed to clone the respective package repository locally. The package repositories are right now located in two places:
Source-git repositories technology is still under heavy development and as you can see there is a very few such repositories. If there is one which you'd like to see included, please reach to <firstname.lastname@example.org> or someone in the packit team.
In our example below, we are going to pick source-git repository for rpm package. We’d navigate to https://git.stg.centos.org/source-git/rpm, fork it and clone our fork locally.
2.1. Source-git vs. dist-git
If you’re familiar with how packaging is done in CentOS and Fedora, you may know dist-git repositories: each repository represents a source RPM package and contains all the RPM source files (RPM spec file, upstream tarball checksum and optionally patch files and other files).
With source-git, we need to have all the RPM source files, but we want to present them in the upstream repository format. Currently, we are just unpacking an archive for the corresponding upstream release, in future, we are planning to utilize real upstream git history. For more details on how to work in a source-git repository, please head on to packit's documentation.
2.2. Clone it
$ git clone ssh://email@example.com/forks/tomastomecek/source-git/rpm-demo.git
Don’t forget to set up the upstream remote for the main repository (NOT upstream project):
$ git remote add upstream ssh://firstname.lastname@example.org/source-git/rpm.git
3. Create a change
This is the part where you can shine! There are two types of changes you can make:
1. Change the source code
2. Change packaging
For both, you can just edit the files and commit the change. The spec file is present in the SPECS directory. For changes in all other files, patch files would be generated for every commit and added to the spec file. Please do not add any patches to the spec file, this is being handled automatically.
We’d use here the standard git workflow you may know from upstream repositories: push commits to your fork and create a pull request.
4. Propose a change
Once the PR is up, automation would pick up the change and build it - there will be RPMs with your change available so you can try them out or just make sure it builds fine.
5. Get a review
In order for your change to land in RHEL and CentOS Stream, it needs to be reviewed and approved by the RHEL maintainer. Don’t worry, they are aware of your pull request, they may just be busy with their day-to-day job.
As new changes are coming to CentOS Stream, there may be a need to rebase your pull request.
7. Will it get accepted or rejected?
Just to be clear, your PR is never going to be merged, even when accepted. It needs to land in the development version of RHEL first so that it can be pulled back to CentOS Stream. Once that happens, you'll be able to see it while being set as the contributor of the particular change.
Once your change is accepted, it will be marked with the label "accepted". Our automation will create a corresponding bugzilla with the patch attached and then it’s up to the RHEL maintainer to pick it up, commit and build internally so that it can land back into CentOS Stream - this process can take some time, so please be patient.