origin: an upstream change needs a second pull request here

Every upstream change needs a follow-up pull request here

The readme is explicit about the sequence. Backports and carries against upstream go to the fork repository, and if a change merged there needs to land here then it is necessary to follow up with a pull request to this repository that bumps the vendoring. A helper script does the mechanical part:

$ hack/update-kube-vendor.sh <openshift/kubernetes branch name or SHA>

Consequence: there is no single-pull-request path for anything that touches upstream, and the second step is easy to forget because nothing in the first repository can see this one. There is a fake-bump mode for validating a change before it merges upstream, which takes a fork repository name as a second argument, so a contributor can open both pull requests at once. That is a thoughtful affordance and it also means the review burden is doubled by construction. The readme also notes that after the script has run, the vendoring changes still have to be committed and proposed, which is the step that turns a mechanical update into a reviewable one.

The same branch name means different things in the two repositories

The readme states the correlation rule and then gives the exception in a parenthesis, with the previous repository's default branch name mapping to this repository's default branch name:

e.g. `master` in `openshift/kubernetes` is vendored into `main` in `origin`

Consequence: the branch names are correlated but not identical, and the mapping is the kind of fact you have to read rather than infer. Any script that moves a commit between the two repositories, any bookmark that assumes a name is shared, and any mental model built from the upstream project has to carry this mapping. It is the kind of trap that costs an afternoon once and then never again, and it is documented in a sentence that is easy to skim. The older branches are the exception in the other direction: carries and backports for them go straight to this repository, and the other repository is only involved for rebases.

The documented workaround disables checksum verification

There is a section on a specific failure. If the update script returns a gone error, it may be that the language's checksum server does not yet know about the target commit, and the workaround given is to set an environment variable that turns the checksum database off:

$ GOSUMDB=off hack/update-kube-vendor.sh <branch name or SHA>

Consequence: the tool that updates your dependencies can be run with integrity checking disabled, in a repository whose release process depends on that tool. That is the right trade when the alternative is waiting for a public database to index a commit you just pushed, and it is the kind of instruction a security review will want to see explained rather than discovered. The error text is quoted in full in the readme, including the server response, which is unusually helpful for something that would otherwise be a wall of output from a module tool.

Disabling a test means finding the right repository first

Test exclusion is described as having moved from test annotations to filtering based on environmental selectors, which can filter or skip tests according to the cluster's environment and configuration. The rules themselves live in two files in each of the two repositories, and the readme ends the section by telling you which repository to edit for which set of tests. Consequence: the model is better than annotations because it is configuration rather than code, and the cost is that the question why did this test not run is answered in another repository half the time. Four files and two repositories for one policy is the maintenance surface that creates. Selectors are described as matching tests known to be incompatible with particular configurations, so the mechanism assumes the list grows as deployments diverge rather than as bugs are found.

Three dependency managers and a committed diff

The repository root carries the language's own manifest and checksum file, a vendored directory, an `apm.yml` file with its `apm.lock.yaml` lockfile, and a committed `deps.diff` file. Consequence: several dependency-related artefacts sit side by side at the root, and a contributor has to know which one a change belongs in. The vendored directory is also where the build system lives, since the makefile includes several of its own files from inside it, so a routine dependency bump can change your build targets as well as your code. There is also a `verify-origin` make target whose job is to run the repository-specific checks, calling `hack/verify-jsonformat.sh`, `hack/verify-generated.sh` and `hack/verify-tls-ownership.sh`.

The build definitions are inside the vendored tree

The build file's first act is to include four makefiles from the vendored copy of the project's build machinery:

include $(addprefix ./vendor/github.com/openshift/build-machinery-go/make/, \

Consequence: the targets you type are defined by a dependency rather than by this repository, which is a defensible way to keep a large project consistent and means an update to that dependency is a change to your build interface. It also means the file a new contributor reads first is mostly includes, and the real targets are somewhere else. The image target generated from that machinery builds against a fixed internal registry path and a fixed version segment, so the artefact name encodes which product line the branch serves.

Six assistant configurations and four instruction files

The root carries configuration directories for coding assistants and agent tooling (`.agentic/`, `.apm/`, `.claude/`, `.cursor/`, `.gemini/`, `.opencode/`), three markdown instruction files (`AGENTS.md`, `CLAUDE.md`, `GEMINI.md`), and two more machine-readable descriptor files (`.mcp.json`, `opencode.json`), alongside the usual repository files.

Consequence: conventions for working in this repository are written down in many places, and the README does not say how they are kept in agreement. That is a lot of surface for a project whose actual contribution path is already two repositories and a vendoring bump, and it is the kind of thing that makes a newcomer wonder which file to believe.

The tags stopped in 2018 while the branches describe version four

The three most recent releases are all version three, the newest from October 2018, and they include a release candidate from June of that year. The branches the readme describes are four point six and above, and the last push recorded for the repository is from 2 November 2026.

Consequence: the tags are historical and the branch is the version, which the readme never says. Anything that reads the latest release to work out what is current gets something eight years old, and a tool that installs by tag installs a version whose maintenance model no longer exists. It is also why the readme explains branch-by-branch maintenance rather than describing a single supported line.

Editorial conclusion

origin fits a contributor working on the OpenShift conformance suite who is already inside the two-repository workflow and treats the vendoring bump as part of the change. It does not fit someone who wants to send a fix to a test and have it reviewed once, because every upstream change is two pull requests in two places. It also does not suit anyone reasoning about versions from the repository's tags, since those stopped eight years ago. Before starting, work out which branch's workflow applies, since older branches still build a binary the newer ones dropped, and check the vendoring instructions before you write the test.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. openshift/origin on GitHub
3. Project website
4. README
5. Releases