@salimma you also mentioned something about z tag for RHEL-based builds, IIRC?

yes, instead of el9 and el10 you get el9_z and el10_z

see https://cbs.centos.org/koji/packageinfo?packageID=129

The tags are also different, the prefixes are hyperscale9- and hyperscale10- instead of hyperscale9s- and hyperscale10s-

(yes, this is inconsistent but we're stuck)

The containers aren't abandoned, we're having trouble moving them to Koji which has prevented updating them.

See: https://gitlab.com/CentOS/infra/tracker/-/issues/1659

occasional

This needs a bit of a rework. After the gitlab move SIG branches are kept in dedicated repos under gitlab.com/centos/hyperscale/rpms -- that's the upstream from our POV. Historically we've called gitlab the redhat/centos-stream upstream, and sometimes we add fedora too if we need Fedora branches

As Neal said we want to keep the container stuff

Updated:
- Brought back the container wikis
- Added explanation for hyperscale9-packages-facebook-el9-build and RHEL 10 equivalent
- Per @dcavalca's comment, renamed upstream to centos-upstream

The instructions on needing a CentOS account is still valid - perhaps also mention it could be a Fedora account as well, so if you ever want to work upstream in Fedora just create a Fedora account.
Though I'm not sure exactly how to force the permission sync, is it just logging back into gitlab now or something else.

The instructions on needing a CentOS account is still valid - perhaps also mention it could be a Fedora account as well, so if you ever want to work upstream in Fedora just create a Fedora account.
Though I'm not sure exactly how to force the permission sync, is it just logging back into gitlab now or something else.

Not if you only want to contribute externally. Anyone with regular GitLab account can open a MR, and we can take it from there.

Added the instructions how to link Gitlab and Fedora accounts together via SSO.

Added the instructions how to link Gitlab and Fedora accounts together via SSO.