Skip to content

Proposing an update

A proposed update starts as a fix for a CentOS Stream package. The SIG builds it while the fix makes its way into Stream, and retires the build once Stream ships the fix.

Before you start

The fix should be headed for CentOS Stream: submitted as a merge request against the package in redhat/centos-stream/rpms, ideally with a Red Hat Jira issue, and likely to be released in Stream within one RHEL minor release. See the charter for what is in scope.

Prefer fixes that can be backported to the version Stream ships. If a version bump is unavoidable, it needs some indication from the Stream or RHEL maintainers that the new version will land soon, by the next minor release.

Tools

The SIG's tools come from sandogasa:

  • cpu-sig-tracker (cargo install cpu-sig-tracker) finds or files the Jira issue, opens the merge request, and tracks the update afterwards.
  • cbspkg pushes the SIG branch and builds on CBS. It is not on crates.io yet; build it from the sandogasa repository.

Both keep their GitLab and Jira tokens in the desktop keyring: run cpu-sig-tracker config and cbspkg config once to set them up. cpu-sig-tracker mr also needs centpkg with a GitLab token (centpkg set-distgit-token).

Workflow

As a contributor:

  1. Clone the package from CentOS Stream, not from the SIG's project, and commit the fix on a branch off c<N>s. The tools work out the package and release from the checkout's remotes and branch.
  2. Find the Jira issue for the fix, or draft and file one: cpu-sig-tracker jira <package> --branch c<N>s (--file to file the draft). Add Resolves: RHEL-NNNN to the commit message.
  3. Open the merge request: cpu-sig-tracker mr. It forks the Stream project with centpkg, pushes the branch, and opens the merge request from the commits.
  4. Ask the SIG to pick it up, on the channels or at a meeting, with the merge request's URL.

From there, a SIG member pushes the change to the SIG's project as a c<N>s-proposed-RHEL-NNNN branch, builds it on CBS (the build gets the ~proposed dist tag prefix, so the spec needs no change beyond the merge request's), opens a tracking issue in the package's project under CentOS/proposed_updates/rpms, and publishes the build to the testing repository. Once it has been tested, it is released. See Building packages for those steps.

Fixing the same issue in more than one release means one merge request per branch, c9s and c10s separately.

See Update lifecycle for what happens after that.