# Repository Migration Plan

We need to figure out exactly how we’re going to move to the CaC/compliance-operator.

## Tasks

- [x] Enable OpenShift CI on CaC/CO
- [x] Merge https://github.com/openshift/compliance-operator/pull/822
- [x] Merge https://github.com/openshift/compliance-operator/pull/820
- [x] Close https://github.com/openshift/compliance-operator/pull/823 after CI reports a failure
- [x] Merge https://github.com/openshift/compliance-operator/pull/824
- [x] Ensure CaC/CO has approvers file with valid users
- [x] Sync changes from openshift/CO to CaC/CO
- [x] Port open issues from openshift/CO to CaC/CO
- [x] Mark openshift/CO as a read-only repository

## Open Questions

- How are upstream builds going to work?
- Should we still push content to Quay with each CaC commit so we're not completely reliant on GitHub images (thinking about outages)?
- Yes, having content in two places is never a bad thing if it's free
- How do we keep openshift/CO in sync with CaC/CO?
- Create a `release-stream` branch in openshift/CO
- It would be nice if the upstream (CaC/CO) release would...
- Do we want to associate each upstream release to a commit of CaC/content?

Today, if we released the CaC/CO, we would:

1. Create a branch for 0.1.51 (`release-v0.1.51`), tag it (`v0.1.51`), release
2. Sync the fork to openshift/CO, which should contain the new branch and tag
3. Downstream just continues doing what it does today (midstream would still need a pointer)

Improvement:

1. In CaC/CO we make a `ocp-0.1` (e.g., `release-0.1`) branch.
2. When we release a new version on `0.1`, eg. `0.1.51`, the release PR is merged into master and tagged with `v0.1.51`. (no more `release-0.1.x` branches).
3. Fast-forward `ocp-0.1` to tag `v0.1.51`
4. Update midstream to point to CaC/CO `ocp-0.1` (only once)

We can add `ocp-0.1` as a protected branch in CaC/CO

It sounds like we have two processes

1. We need one process for releasing upstream
2. We have another process for actually updating the openshift/CO fork