wiki/docs/sop/sop_upstream_prep_checklist.md

title
Generalized Prep Checklist for Upcoming Releases

This SOP contains general checklists required by SIG/Core to prepare and plan for the upcoming release. This work, in general, is required to be done on a routine basis, even months out before the next major or minor release, as it requires monitoring of upstream's (CentOS Stream) work to ensure Rocky Linux will remain ready and compatible with Red Hat Enterprise Linux.

Contact Information

Owner	SIG/Core (Release Engineering & Infrastructure)
Email Contact	infrastructure@rockylinux.org
Email Contact	releng@rockylinux.org
Mattermost Contacts	@label @neil @tgo @skip77 @mustafa @sherif @pgreco
Mattermost Channels	~Infrastructure

General Upstream Monitoring

It is expected to monitor the following repositories upstream, as these will indicate what is coming up for a given major or point release. These repositories are found at the Red Hat gitlab.

• centos-release
• centos-logos
• pungi-centos
• comps
• module-defaults

These repositories can be monitored by setting to "all activity" on the bell icon.

Upon changes to the upstream repositories, SIG/Core member should analyze the changes and apply the same to the lookahead branches:

• rocky-release

  • Manual changes required

• rocky-logos

  • Manual changes required

• pungi-rocky

  • Run sync-from-upstream

• peridot-rocky

  • Configurations are generated using peridot tools

• comps

  • Run sync-from-upstream

• rocky-module-defaults

  • Run sync-from-upstream

General Downward Merging

Repositories that generally track for LookAhead and Beta releases will flow downward to the stable branch. For example:

* rXs / rXlh
      |
      |----> rX-beta
                |
                |----> rX

This applies to any specific rocky repo, such as comps, pungi, peridot-config, and so on. As it is expected some repos will deviate in commit history, it is OK to force push, under the assumption that changes made in the lower branch exists in the upper branch. That way you can avoid changes/functionality being reverted on accident.

General Package Patching

There are packages that are patched typically for the purpose of debranding. List of patched packages are typically maintained in a metadata repository. The obvious ones are listed below and should be monitored and maintained properly:

• abrt
• anaconda
• anaconda-user-help
• chrony
• cockpit
• dhcp
• dnf
• firefox
• fwupd
• gcc
• gnome-session
• gnome-settings-daemon
• grub2
• initial-setup
• kernel
• kernel-rt
• libdnf
• libreoffice
• libreport
• lorax-templates-rhel
• nginx
• opa-ff
• opa-fm
• openldap
• openscap
• osbuild
• osbuild-composer
• PackageKit
• pesign
• python-pip
• redhat-rpm-config
• scap-security-guide
• shim
• shim-unsigned-x64
• shim-unsigned-aarch64
• subscription-manager
• systemd
• thunderbird