CentOS Stream support

[lbarcziova]

• Support proposing new releases to CentOS Stream packit#1979
• Document the ‹propose-downstream› workflow for CentOS Stream packit.dev#796
• The pull-from-upstream for c9s will auto reference to Fedora rawhide bug packit#2259
• Support pulling new releases into CentOS Stream #2068
• Be able to specify a Jira ticket when doing a release to CentOS Stream #2190
• React to CentOS Stream dist-git comments #2191
• Vetting process for propose-downstream #2208
• Upstream verification of the »release« #2209
• marketing: documentation, blog post, workshop

---

Related

• RFE: Support for CentOS Stream Koji packit#1779
• RFE: centos-stream-all packit#1999
• RFE: Support for CentOS CBS Koji packit#2002

Possible users / uscases

• Rubygems maintained by pvalena: https://src.fedoraproject.org/user/pvalena/projects

[ckelleyRH]

UX suggestion/warning:

Whatever you do, when you propose a PR/MR to CentOS Stream in the gitlab.com/redhat namespace, DO NOT use any branch names of the form rhel-*.

TL;DR - These are protected branches in origin, and there is a bug in GitLab that prevents the Stream pipelines from running if the remote branch name shadows a protected branch. Stream maintainers keep crashing into this, because naming your branch after the issue you are trying to fix is an entirely reasonable thing to do isn't it. 😆 If you guys do this, you will get auto-carnage in additional to the current manual carnage.

[mfocko]

I think it shouldn't be a problem, right now we use:

$version-$chroot-update-$job_type

and we were considering leaving out the $version for the sake of not spamming with PRs… if it came to the worst, I guess we could prefix it with packit, so there would be something like:

packit/$version-$chroot-update-$job_type

---

$job_type ∈ { pull_from_upstream, propose_downstream }

[ckelleyRH]

Sounds good!

[lachmanfrantisek]

@mfocko I am for the prefix. It's similar to what pre-commit is doing (i.e. the pre-commit-ci-update-config branch)

[lachmanfrantisek]

@ckelleyRH thanks for the suggestion!

[lachmanfrantisek]

We want to aim for a couple of projects to be onboarded for the next quarter. The number is yet to be decided.

[lsm5]

We want to aim for a couple of projects to be onboarded for the next quarter. The number is yet to be decided.

@lachmanfrantisek what's the latest on this? and include us please :)

EDIT: C9S could be a problem for us given the lack of %autorelease and %autochangelog, but if this will also include c10s whenever that releases, we'd be all for it.

[lbarcziova]

hi @lsm5 ! We have the initial support for propose_downstream and this is described in the documentation here: https://packit.dev/docs/configuration/upstream/propose_downstream#syncing-the-release-to-centos-stream. We will be happy if you will try that out! You can configure the branches similarly as for Fedora (see the example). Which repositories would you be interested in onboarding?

Besides that, support for pull_from_upstream is being implemented as well in #2068.

[lsm5]

hi @lsm5 ! We have the initial support for propose_downstream and this is described in the documentation here: https://packit.dev/docs/configuration/upstream/propose_downstream#syncing-the-release-to-centos-stream. We will be happy if you will try that out! You can configure the branches similarly as for Fedora (see the example). Which repositories would you be interested in onboarding?

I will defer to @jnovy as he's our main centos and rhel guy, but I think we should be safe to enable this for the c10s branches for these packages:
aardvark-dns, buildah, container-selinux, crun, netavark, podman, skopeo

There might be more down the line, but I think we can start with these.

[mfocko]

Update

We have planned #2068 as a complexity/single-task card, yet it appears that it requires much more work than has been anticipated. Given that, it makes more sense to keep #2068 as the epic for the release-sync to CentOS Stream as any other subtasks of this epic are more related to further improvements to the user experience (e.g., Jira or vetting) with running Packit for CentOS Stream rather than the release-syncing itself.

---

providing an update with regards to the recent Q3 planning; cc @lachmanfrantisek