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. 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 the meantime, you can contribute your change to a dist-git repository.
2.1. Fork & clone
Once you located the repository in the web interface, fork it and clone it.
$ git clone ssh://email@example.com/forks/$user/rpms/rpm.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/rpms/rpm.git
Once cloned locally, you should check out the c8s branch. If there is no such branch, locate c8 - this means there are no CentOS Stream changes and the package is tracking latest CentOS Linux release.
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. 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. 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 for the particular component. If you are not getting any feedback feel free to reach out to #centos-devel on freenode.
As new changes are coming to CentOS Stream, there may be a need to rebase your pull request.
6. 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.
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). But the repository itself doesn't contain source code - you need to execute %prep phase to see it.
With source-git, the sources are unpacked and downstream changes are layered on top as additional commits. The repositories don't contain upstream git history now, instead we are unpacking an archive for the corresponding upstream release and this is the first commit. For more details on how to work in a source-git repository, please head on to packit's documentation.
7.1. How to submit a change in the source-git repo
You are changing the code directly in a source-git repo. We have then automation set up to generate a SRPM from source-git repositories.
Changes to spec files don't need any special handling, the situation is different for patches: there are two ways how to handle spec file patch files.
7.1.1. Define a patch in the spec file
This is the preferred way since you are in full control.
If you are changing source code and you know that a patch in the spec is needed, add it to the spec file with a name of your choice:
Now you need to annotate commit message with the respective change
We need this change in CentOS Stream patch_name: my-special-change.patch present_in_specfile: true Signed-off-by: Tomas Tomecek <email@example.com> --- src/code.c | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-)
The automation, packit, then reads the commit message, knows that the patch is already defined in the spec and creates a patch file with the name set in "patch_name" from the respective commit.
7.1.2. Let the patch be generated
If packit, the tool which works with the source-git repo behind the scenes, does not find such metadata as defined above in a commit message:
1. it adds a new patch entry in the spec file
2. and generates a patch file from the respective commit
This is convenient but prone to errors. In case this method does not work, please set the metadata as described in the method above.
7.1.3. After a pull request is created
When you submit a pull request for source-git, automation will 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.
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.